knowning that you want to keep BST as OS neutral as possible, are the chances slim to none for you to consider adding a simple OLE automation interface to the Win side?
knowning that you want to keep BST as OS neutral as possible, are the chances slim to none for you to consider adding a simple OLE automation interface to the Win side?
thanks for your time
- Howard
There may well be a platform neutral way of doing whatever it is you want however. What are you actually trying to achieve?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Something that has been bothering me about this whole Ubuntu serial port thing. It seems if I open the BST terminal that it doesn't work. Sure, if I say reset I can see that the target has been reset so the port is connected ok but I do not receive any serial traffic from my menu system on the target. Now if I open GtkTERM I can communicate with it fine and I can also toggle the DTR and reset the Prop etc. So Ubuntu seems to be behaving fine, but not with BST. BST seems to behave fine with SimplyMEPIS and other platforms, but BST and Ubuntu don't seem to like each other.
Peter Jakacki said...
but BST and Ubuntu don't seem to like each other.
Which is very odd as that is the operating system I develop it under.
Thanks for the tip of GTKTerm. I'll trace it and find out what its doing differently with the port.
I've just had a look at the Ubuntu patches for the serial port and they do not have the fix for the ftdi bug in the kernel. I'm unsure as to why GTKTerm works, and I'll investigate that, but I maintain the current Ubuntu beta kernels have a broken ftdi driver. I can verify that here on my own system, and I can verify it at the source level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Something that has been bothering me about this whole Ubuntu serial port thing. It seems if I open the BST terminal that it doesn't work. Sure, if I say reset I can see that the target has been reset so the port is connected ok but I do not receive any serial traffic from my menu system on the target. Now if I open GtkTERM I can communicate with it fine and I can also toggle the DTR and reset the Prop etc. So Ubuntu seems to be behaving fine, but not with BST. BST seems to behave fine with SimplyMEPIS and other platforms, but BST and Ubuntu don't seem to like each other.
Ok, here's the deal. I've just spent about 4 hours working on this bug and I now know precisely what the issues are. As a side effect, I also found the bug heater was seeing with the kernel oops.
Peter, your bug is with the Ubuntu kernel. It was broken in the very early .31-rc process (months ago) and the fix only went into 2.6.31.5 on the 17th of Oct. The last Ubuntu kernel update was on the 16th, so the bug is still in the Ubuntu kernels. The bug does not manifest itself if you open the serial port with the O_NONBLOCK flag set (which is what minicom and gtkterm do). I, on the other hand, open the port without that flag. Ordinarily you can open the port without the O_NONBLOCK flag and then fcntl() the port to set the O_NONBLOCK flag afterwards. In this particular instance, this does not work around the bug. I found I could work around it by changing the serial code to open the port O_NONBLOCK, but that then has the knock on effect of me having to completely re-work some of the serial timing handling. I'd much rather just wait for the new kernels to flow upstream. The current broken behaviour is not consistent and occasionally it will let data though, which might explain why you occasionally saw it work.
Heater, your bug was present until about the 2.6.30 kernel and involves a bad refcount on the port. If the ftdi hardware goes away while it's still open, the kernel can oops. Prior to the latest -Pre of bst, if the port actually went away in that fashion (due to a kernel oops) bst would try and close the non-existent port and would crash. I've fixed it in bst, but if you are still using an older kernel and you have a flaky usb cable you might still see the odd kernel oops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Brad, thanks for this excellent tool! I use it under Debian 5 - works just fine. Actually, I am mostly interested in command-line tool, since I use VIM for all my code editing. I setup a makefile for project, and just call make from VIM. But there is a small problem that makes this style of work annoying - VIM cannot interpret the messages bstc writes to stdout. Even if the compilation is successfull, VIM interprets the messages as errors, resulting in opening a blank file. For example, seeing this:
Compiled for i386 Linux at 09:14:50 on 2009/05/08
VIM thinks there is an error in file named "Compiled for i386 Linux" [noparse]:)[/noparse]
Is it possible to make bstc to output nothing on successfull compilation, and report warnings and errors in same format as GCC does? By default, this mode would be off, and turned on with a command-line switch.
Andrey Demenev said...
Brad, thanks for this excellent tool! I use it under Debian 5 - works just fine. Actually, I am mostly interested in command-line tool, since I use VIM for all my code editing. I setup a makefile for project, and just call make from VIM. But there is a small problem that makes this style of work annoying - VIM cannot interpret the messages bstc writes to stdout. Even if the compilation is successfull, VIM interprets the messages as errors, resulting in opening a blank file. For example, seeing this:
Compiled for i386 Linux at 09:14:50 on 2009/05/08
VIM thinks there is an error in file named "Compiled for i386 Linux" [noparse]:)[/noparse]
I use and love vim, but I'm a firm believer in "the right tool for the right job" and apparently vim is just too inflexible to interpret a sane output. I can't believe it relies on stdout to determine an error status. That's what result codes were made for. Maybe you should switch to Emacs [noparse];)[/noparse]
If you send me a good example of precisely the format gcc outputs that vim is going to sanely interpret I'll try to get something working for you.
Even better, in addition to that, send me a test project with all the vim automation I can test with locally here and I'll make sure it works properly too [noparse]:)[/noparse]
I use Ubuntu 8.04 on my desktop and laptop, and whatever the current Debian stable is on my servers. I do test all the tools on i386 and x86_64 Debian before I release them.
I used Debian exclusively on my desktops until Ubuntu 6.06 was released (I used to just use Windowmaker and heaps of automation) but after trying Ubuntu and having Gnome pretty much just work for me, I've kinda stuck with that on my daily drivers. My TV box still uses Debian and WindowMaker, but it PXE boots with an NFS root. Nice to keep it small and fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Just an update. Ubuntu 9.10 has been released and despite a bug being raised on this issue, the kernel still contains the buggy code.
Has anyone other than Peter seen this issue with Ubuntu? If not, I strongly recommend that those using bst on Ubuntu avoid upgrading to 9.10 until the bug has been resolved, or use a self-compiled kernel based on vanilla mainline.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.lt's not particularly silly, is it?
On another thread, someone was trying out the AAC preprocesser (Augmented Assembly Code) and said that he would love to see it somehow useable from bst (and generate LMM code).
I responded that AAC is young yet (beta testing for only 2 days) and its value to the community is yet to be established.
I also said that it uses .Net Framework 2.0 which was not a happy thing for you.
Still, I thought I should ask whether you have any interest in pursuing some kind of connection.· Maybe I need to rewrite it as a console app.· I'm open to ideas.· I won't be offended if you feel it's not worth the effort (although it would be nice if you qualified the rejection with a "not yet" qualifier).
On another thread, someone was trying out the AAC preprocesser (Augmented Assembly Code) and said that he would love to see it somehow useable from bst (and generate LMM code).
I responded that AAC is young yet (beta testing for only 2 days) and its value to the community is yet to be established.
I also said that it uses .Net Framework 2.0 which was not a happy thing for you.
Still, I thought I should ask whether you have any interest in pursuing some kind of connection. Maybe I need to rewrite it as a console app. I'm open to ideas. I won't be offended if you feel it's not worth the effort (although it would be nice if you qualified the rejection with a "not yet" qualifier).
Really, my only proviso is the code *must* be supported across all 4 platforms (I count OSX PPC & OSX Intel as separate platforms), and it must work without touching the disk. No input/output or temporary files. So the only real option is piped stdio.
If we can manage that, and we can thrash out a usable and extensible interface that allows proper error locations and does not leave the user guessing, then I'm happy to have a go at it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Someone suggested that BST could highlight matching pairs of #ifdef / #endif when the cursor is on one of them
I'd like to suggest an alternative. I'm not normally a great user of IDE's, with the major exception of Prop work, but I've been using the QT Creator IDE that comes with the QT GUI tool kit a lot recently. Of course it has syntax highlighting for #ifdef etc but it also has this great feature that the actual code that is not used because it is excluded by a false #ifdef is greyed out. Rather like commented out code is "greened out". Or which ever colour.
Makes it dead obvious which bits of code you are actually about to compile, or not, at any moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
"Someone suggested that BST could highlight matching pairs of #ifdef / #endif when the cursor is on one of them"
That would be me, wishing for a perfect world. Heaters surgestion is so much better, but more work for Brad. I just wish I was anyway close of being capable to help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Brad: Let me assure you your code definately is no embarassment.
1. It works and any bugs discovered are fixed so quickly.
2. It is cross-platform... a feat on it's own
3. It has an integrated IDE, editor, compiler, loader/programmer, and terminal.
4. It has extra features required for more complex solutions.
Sure, there are some things it does not do like I would like, but until I can think of constructive ways to make it better, it's my problem, not yours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Brad: Let me assure you your code definately is no embarassment.
1. It works and any bugs discovered are fixed so quickly.
2. It is cross-platform... a feat on it's own
3. It has an integrated IDE, editor, compiler, loader/programmer, and terminal.
4. It has extra features required for more complex solutions.
Sure, there are some things it does not do like I would like, but until I can think of constructive ways to make it better, it's my problem, not yours.
I like that attitude [noparse]:)[/noparse]
If you saw the code for the highlighter you'd probably wonder how it worked at all. Trust me, it's an embarrassment.
You guys have suggested stuff I just would never think of, so it all gets written down and when I wake up at 3AM and go "Oh, I know an easy way to do that", then it gets implemented.
I'm actually spending a bit less time on it at the moment as I've gone back to the PIC for a couple of my bigger projects, and to be honest the time spent in other environments has me thinking about some of the niggles in bst I'd like to fix. Now I just need time to get them under control [noparse]:)[/noparse] (well, those and the bugs anyway)
I have conclusively proved recently that jamming screwdrivers in between the scl and sda pins of an eeprom while you are downloading to it will cause no immediate permanent damage (what it does to the drivers long term I can only guess). So despite my best efforts to blow up a proto board, I just have not managed to do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
That's the problem with creating a brilliant piece of software. People use it. Then they want it to be more brilliant.
I would not worry to hard about the #ifdef thing. We only think we want it because we have tangled ourselves up with an excess of conditional compilation spaghetti. If it wakes you up at 3 a.m. you can blame us and go back to sleep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I must confess my best code is written in the wee small hours
I taught programming courses for a few years and there was not one course I taught where a student did not ask or suggest something where I learnt a new trick or more. That is what I love about this forum. There are so many ideas - just not enough time to implement them
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
If You write bad program .... people will not use it ... maybe look one time.
BUT as You are writen Excellent TOOL to program propeller .... Them test it to scopes that are most imposible.
And that give them ideas why not have ..... THAT Litle more in it ... To test next step of imposible scopes.
Thatks for Excellent work
Regards Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
A pencil and paper are vital. Only then can you diferentiate between the dreamt and the real. I always have that nagging doubt that I had solved something, but forgot before dawn.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Hi Brad, I'm trying out bst for the first time and have run into a snag. I'm on Mac OS X 10.6.2, and when I try to launch the bst GUI it brings up an empty white box and then the spinning rainbow cursor (indicating that the application is not responding to the WindowServer).
Even more curiously, trying to sample or get a VM map of the hung app results in an unpromising error from dyld:
---8<---
$ vmmap bst
Found process 12775 (bst.osx) from partial name bst
Found process 12775 (bst.osx) from partial name bst
Virtual Memory Map of process 12775 (bst)
Output report format: 2.2 -- 32-bit process
Nak said...
Hi Brad, I'm trying out bst for the first time and have run into a snag. I'm on Mac OS X 10.6.2, and when I try to launch the bst GUI it brings up an empty white box and then the spinning rainbow cursor (indicating that the application is not responding to the WindowServer).
No, I'm a bit stumped really.
Which particular version of bst are you trying to run?
Is this a 64 bit or 32 bit machine?
How much ram do you have?
Do you have any networked drives mapped (anything remote in /Volumes) ?
I have tested it on 10.6.1, but I've not upgraded to 10.6.2 yet. If it seems this might be an issue I'll do that and test, but I only have a Core Duo Mac Mini to test with.
The empty white box sounds like it starts to paint the splash screen and then explodes.
<edit> Oh my goodness. I've just spotted a *huge* bug in the OSX code that will hit you if this is the first time you've booted bst. It should not cause it to crash, but it will cause it to scan your entire filesystem instead of only just your home directory. To test, I mapped one of my nfs shares across a vpn over a slow net link, and bst sat there with the splash screen for about 10 minutes while it scanned the network share. Maybe start it up and grab a cup of coffee to see if it eventually comes up.
I know you can't use strace on OSX, but a quick google shows a reference to 'fs_usage'. I'm away from my macs, so I can't investigate further, but if you could run something like that to see if it's doing a ton of stat() calls in the background as it crawls the directory trees it might help pin it down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
It fixes the home directory glitch for new OSX users, and it now tries to provide a status update to the splash screen and window manager every 500ms while it's scanning big, slow file shares (you will see the full stops at the end of the top caption oscillate). Let me know if it helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Ah, that explains it. I was VPN'd into the network at work, so there were a ton of NFS shares automounted. I tried again after shutting down the VPN and this time bst did come up. (There was still some delay, but I let it grind while I was reading the Propellor manual and after awhile it came up. Subsequent restarts don't seem to have the same initial delay.)
To answer your questions about my Mac's configuration anyway (just FYI and for other Mac users), here is what System Profiler reports in the Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro4,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.5 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 6 MB
Memory: 4 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP41.00C1.B00
SMC Version (system): 1.27f2
Comments
knowning that you want to keep BST as OS neutral as possible, are the chances slim to none for you to consider adding a simple OLE automation interface to the Win side?
thanks for your time
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There may well be a platform neutral way of doing whatever it is you want however. What are you actually trying to achieve?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Something that has been bothering me about this whole Ubuntu serial port thing. It seems if I open the BST terminal that it doesn't work. Sure, if I say reset I can see that the target has been reset so the port is connected ok but I do not receive any serial traffic from my menu system on the target. Now if I open GtkTERM I can communicate with it fine and I can also toggle the DTR and reset the Prop etc. So Ubuntu seems to be behaving fine, but not with BST. BST seems to behave fine with SimplyMEPIS and other platforms, but BST and Ubuntu don't seem to like each other.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Which is very odd as that is the operating system I develop it under.
Thanks for the tip of GTKTerm. I'll trace it and find out what its doing differently with the port.
I've just had a look at the Ubuntu patches for the serial port and they do not have the fix for the ftdi bug in the kernel. I'm unsure as to why GTKTerm works, and I'll investigate that, but I maintain the current Ubuntu beta kernels have a broken ftdi driver. I can verify that here on my own system, and I can verify it at the source level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Ok, here's the deal. I've just spent about 4 hours working on this bug and I now know precisely what the issues are. As a side effect, I also found the bug heater was seeing with the kernel oops.
Peter, your bug is with the Ubuntu kernel. It was broken in the very early .31-rc process (months ago) and the fix only went into 2.6.31.5 on the 17th of Oct. The last Ubuntu kernel update was on the 16th, so the bug is still in the Ubuntu kernels. The bug does not manifest itself if you open the serial port with the O_NONBLOCK flag set (which is what minicom and gtkterm do). I, on the other hand, open the port without that flag. Ordinarily you can open the port without the O_NONBLOCK flag and then fcntl() the port to set the O_NONBLOCK flag afterwards. In this particular instance, this does not work around the bug. I found I could work around it by changing the serial code to open the port O_NONBLOCK, but that then has the knock on effect of me having to completely re-work some of the serial timing handling. I'd much rather just wait for the new kernels to flow upstream. The current broken behaviour is not consistent and occasionally it will let data though, which might explain why you occasionally saw it work.
Heater, your bug was present until about the 2.6.30 kernel and involves a bad refcount on the port. If the ftdi hardware goes away while it's still open, the kernel can oops. Prior to the latest -Pre of bst, if the port actually went away in that fashion (due to a kernel oops) bst would try and close the non-existent port and would crash. I've fixed it in bst, but if you are still using an older kernel and you have a flaky usb cable you might still see the odd kernel oops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
VIM thinks there is an error in file named "Compiled for i386 Linux" [noparse]:)[/noparse]
Is it possible to make bstc to output nothing on successfull compilation, and report warnings and errors in same format as GCC does? By default, this mode would be off, and turned on with a command-line switch.
I use and love vim, but I'm a firm believer in "the right tool for the right job" and apparently vim is just too inflexible to interpret a sane output. I can't believe it relies on stdout to determine an error status. That's what result codes were made for. Maybe you should switch to Emacs [noparse];)[/noparse]
If you send me a good example of precisely the format gcc outputs that vim is going to sanely interpret I'll try to get something working for you.
Even better, in addition to that, send me a test project with all the vim automation I can test with locally here and I'll make sure it works properly too [noparse]:)[/noparse]
I use Ubuntu 8.04 on my desktop and laptop, and whatever the current Debian stable is on my servers. I do test all the tools on i386 and x86_64 Debian before I release them.
I used Debian exclusively on my desktops until Ubuntu 6.06 was released (I used to just use Windowmaker and heaps of automation) but after trying Ubuntu and having Gnome pretty much just work for me, I've kinda stuck with that on my daily drivers. My TV box still uses Debian and WindowMaker, but it PXE boots with an NFS root. Nice to keep it small and fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
this is what I think would be the error line that "out-of-the-box" vim would recognize:
*boggle*.
I'll add it to my todo list.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Has anyone other than Peter seen this issue with Ubuntu? If not, I strongly recommend that those using bst on Ubuntu avoid upgrading to 9.10 until the bug has been resolved, or use a self-compiled kernel based on vanilla mainline.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.lt's not particularly silly, is it?
On another thread, someone was trying out the AAC preprocesser (Augmented Assembly Code) and said that he would love to see it somehow useable from bst (and generate LMM code).
I responded that AAC is young yet (beta testing for only 2 days) and its value to the community is yet to be established.
I also said that it uses .Net Framework 2.0 which was not a happy thing for you.
Still, I thought I should ask whether you have any interest in pursuing some kind of connection.· Maybe I need to rewrite it as a console app.· I'm open to ideas.· I won't be offended if you feel it's not worth the effort (although it would be nice if you qualified the rejection with a "not yet" qualifier).
Really, my only proviso is the code *must* be supported across all 4 platforms (I count OSX PPC & OSX Intel as separate platforms), and it must work without touching the disk. No input/output or temporary files. So the only real option is piped stdio.
If we can manage that, and we can thrash out a usable and extensible interface that allows proper error locations and does not leave the user guessing, then I'm happy to have a go at it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I'd like to suggest an alternative. I'm not normally a great user of IDE's, with the major exception of Prop work, but I've been using the QT Creator IDE that comes with the QT GUI tool kit a lot recently. Of course it has syntax highlighting for #ifdef etc but it also has this great feature that the actual code that is not used because it is excluded by a false #ifdef is greyed out. Rather like commented out code is "greened out". Or which ever colour.
Makes it dead obvious which bits of code you are actually about to compile, or not, at any moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
That would be me, wishing for a perfect world. Heaters surgestion is so much better, but more work for Brad. I just wish I was anyway close of being capable to help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
My initial thought is that is a pretty onerous task to throw at the highlighter as you need to teach it to parse code.
I'll put it on the todo list and stew on it for a while. You never know, I might come up with a way to do it fairly easily.
The highlighter has grown to be a bit of an embarrassment really. It's next on the list after the terminal for a revamp.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
1. It works and any bugs discovered are fixed so quickly.
2. It is cross-platform... a feat on it's own
3. It has an integrated IDE, editor, compiler, loader/programmer, and terminal.
4. It has extra features required for more complex solutions.
Sure, there are some things it does not do like I would like, but until I can think of constructive ways to make it better, it's my problem, not yours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I like that attitude [noparse]:)[/noparse]
If you saw the code for the highlighter you'd probably wonder how it worked at all. Trust me, it's an embarrassment.
You guys have suggested stuff I just would never think of, so it all gets written down and when I wake up at 3AM and go "Oh, I know an easy way to do that", then it gets implemented.
I'm actually spending a bit less time on it at the moment as I've gone back to the PIC for a couple of my bigger projects, and to be honest the time spent in other environments has me thinking about some of the niggles in bst I'd like to fix. Now I just need time to get them under control [noparse]:)[/noparse] (well, those and the bugs anyway)
I have conclusively proved recently that jamming screwdrivers in between the scl and sda pins of an eeprom while you are downloading to it will cause no immediate permanent damage (what it does to the drivers long term I can only guess). So despite my best efforts to blow up a proto board, I just have not managed to do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I would not worry to hard about the #ifdef thing. We only think we want it because we have tangled ourselves up with an excess of conditional compilation spaghetti. If it wakes you up at 3 a.m. you can blame us and go back to sleep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I taught programming courses for a few years and there was not one course I taught where a student did not ask or suggest something where I learnt a new trick or more. That is what I love about this forum. There are so many ideas - just not enough time to implement them
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
If You write bad program .... people will not use it ... maybe look one time.
BUT as You are writen Excellent TOOL to program propeller .... Them test it to scopes that are most imposible.
And that give them ideas why not have ..... THAT Litle more in it ... To test next step of imposible scopes.
Thatks for Excellent work
Regards Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
A pencil and paper are vital. Only then can you diferentiate between the dreamt and the real. I always have that nagging doubt that I had solved something, but forgot before dawn.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Even more curiously, trying to sample or get a VM map of the hung app results in an unpromising error from dyld:
---8<---
$ vmmap bst
Found process 12775 (bst.osx) from partial name bst
Found process 12775 (bst.osx) from partial name bst
Virtual Memory Map of process 12775 (bst)
Output report format: 2.2 -- 32-bit process
2009-11-24 20:40:29.056 vmmap[noparse][[/noparse]13000:1707] *** Terminating app due to uncaught exception 'VMUDyld fatal error', reason: 'Attempt to get _dyld_all_image_infos failed'
*** Call stack at first throw:
(
0 CoreFoundation 0x9164940a __raiseError + 410
1 libobjc.A.dylib 0x91f5b509 objc_exception_throw + 56
2 Symbolication 0x92fc2b64 -[noparse][[/noparse]VMUDyld findMachOHeadersInMemory:] + 915
3 Symbolication 0x92fc27a4 -[noparse]/noparse]VMUDyld initWithMachOHeader[noparse]:memory:[/noparse + 132
4 Symbolication 0x92fc266a +[noparse]/noparse]VMUDyld dyldWithMachOHeader[noparse]:memory:[/noparse + 74
5 Symbolication 0x92fd70d3 -[noparse][[/noparse]VMUTask initWithMachTaskContainer:] + 690
6 Symbolication 0x92fd6e09 +[noparse][[/noparse]VMUTask taskWithMachTaskContainer:] + 64
7 Symbolication 0x92ff16f6 -[noparse][[/noparse]VMUVMRegionIdentifier initWithTask:] + 235
8 vmmap 0x00002c67 0x0 + 11367
9 vmmap 0x00002255 0x0 + 8789
)
Trace/BPT trap
--->8---
bstl.osx and bstc.osx command line tools appear to be intact, as I can run them and scratch my head over their -h output just fine.
Any advice?
No, I'm a bit stumped really.
Which particular version of bst are you trying to run?
Is this a 64 bit or 32 bit machine?
How much ram do you have?
Do you have any networked drives mapped (anything remote in /Volumes) ?
I have tested it on 10.6.1, but I've not upgraded to 10.6.2 yet. If it seems this might be an issue I'll do that and test, but I only have a Core Duo Mac Mini to test with.
The empty white box sounds like it starts to paint the splash screen and then explodes.
<edit> Oh my goodness. I've just spotted a *huge* bug in the OSX code that will hit you if this is the first time you've booted bst. It should not cause it to crash, but it will cause it to scan your entire filesystem instead of only just your home directory. To test, I mapped one of my nfs shares across a vpn over a slow net link, and bst sat there with the splash screen for about 10 minutes while it scanned the network share. Maybe start it up and grab a cup of coffee to see if it eventually comes up.
I know you can't use strace on OSX, but a quick google shows a reference to 'fs_usage'. I'm away from my macs, so I can't investigate further, but if you could run something like that to see if it's doing a ton of stat() calls in the background as it crawls the directory trees it might help pin it down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Post Edited (BradC) : 11/25/2009 6:23:44 AM GMT
www.fnarfbargle.com/bst/snapshots
It fixes the home directory glitch for new OSX users, and it now tries to provide a status update to the splash screen and window manager every 500ms while it's scanning big, slow file shares (you will see the full stops at the end of the top caption oscillate). Let me know if it helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
To answer your questions about my Mac's configuration anyway (just FYI and for other Mac users), here is what System Profiler reports in the Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro4,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.5 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 6 MB
Memory: 4 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP41.00C1.B00
SMC Version (system): 1.27f2