Brad, thanks for that. I have had a bit of a play with 0.19.4-pre7 and can get the variables where I want them which is good but there are a couple of other bugs with the IDE. When my mouse hovers over the "open recent" it immediately comes up with "unable to open....". Also I can't open any projects either so it must be a little bug in an annoying place.
Peter Jakacki said...
Brad, thanks for that. I have had a bit of a play with 0.19.4-pre7 and can get the variables where I want them which is good but there are a couple of other bugs with the IDE. When my mouse hovers over the "open recent" it immediately comes up with "unable to open....". Also I can't open any projects either so it must be a little bug in an annoying place.
The other bugs are all expected. I'm half way through a nasty code re-factor which affects project files.
Unfortunately I've had other stuff come up, so I'll get a build out soon with all of the IDE changes reverted but with the compiler change implemented which will at least get things reliable again until I get a chance to finish the project file stuff. Look for 0.19.8-Pre8 in the next hour or two.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I'm having trouble uploading to a DracBlade with BSTC. It looks like the latest BST works fine, but with BSTC I almost always get a timeout. It works once after I used the Python Loader.py to upload and write the EEPROM, then it fails almost certainly. Is there a difference in the timing for the upload between BSTC and BST? Oh, this is on Ubuntu 9.10 BTW.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 12:58:21 PM GMT
Version is late November, 2009. I'll see if I can get a more recent version...
Hmm - I can't seem to find any version later than 20th July 2009. I've tried browsing the directories but they keep going round in circles. I'm a bit stuck here.
Addit - scratch that - found a way out of the circles. Downloading now...
Um - no that was the latest version of BST. I can't seem to get the latest version of BSTC.
And now I am stuck because the latest version of BST is not compiling the dracblade. Error on this line:
r:=sd.popen(string("MYNAME.TXT",0),"r")
It is expecting a value of "1 to 255" where there is the 0.
I tried a value of 1 and that didn't work either. I have gone back to the 15th Jan version for the moment as that works fine. Has the syntax changed in the last couple of months?
@pullmol, no there is no timing difference. Timing has not changed in a number of major releases now. One thing you might look at in bst is in Tools->Compiler Preferences->Options. Is high speed download checked? bstc uses the standard 115,200 baud by default, but bst has defaulted to 230,400 for the last couple of pre-releases. If it's causing you a problem I'll change the default back to "slow 'n steady"
@Dr_A, yes recently a "0" in a String() construct has recently been outlawed as the Parallax compiler considers it invalid (Thanks kuroneko). String() null terminates anyway.
I just tried ...
PUB Fred | X
X := String("MYNAME.TXT",1)
.. on 0.19.4-pre8 and it compiles fine. Can you attach the code that is choking so I can reproduce it locally please?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC said...
@pullmol, no there is no timing difference. Timing has not changed in a number of major releases now. One thing you might look at in bst is in Tools->Compiler Preferences->Options. Is high speed download checked? bstc uses the standard 115,200 baud by default, but bst has defaulted to 230,400 for the last couple of pre-releases. If it's causing you a problem I'll change the default back to "slow 'n steady"
I had enabled the "High speed Propeller Download / Detect" in bst.linux. If bstc uses the 115k2 baud, then this works not (as good) compared to bst's high speed mode. Actually it didn't seem to make a difference if I check high speed or not. bst manages to upload to RAM most of the times, while bstc doesn't. Edit: Now, after trying a few more times, bst doesn't upload in either high or low speed. The whole story seems to behave very erratic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 10:20:39 PM GMT
Re "yes recently a "0" in a String() construct has recently been outlawed"
Thanks for that - I thought I was going a bit crazy. Ok, changed to 1, files recompiled and now work with the latest bst program. Also new zip on the dracblade thread (post1), and a direct link to the bstc download page in case this thread gets hard to find.
Ok, 115 works but the faster option does not. (I am still not sure how you get 115k to work, as the fastest I ever got a N8VEM working reliably was 38k, above that some bytes started getting corrupted, and that uses the same uart chips that are in a PC. All a bit of a mystery. I suspect my ribbon cable is too long - 3 metres. But it still doesn't explain how the BST program manages 115k).
Re pullmoll - can you test it with bst, ie the IDE environment, (not the command line one). Then we at least will be testing on the same software.
I still can't seem to get the latest BSTC command line program. If I go to this page www.fnarfbargle.com/bst.html and to the link bstc down the bottom the date says 20th July, and if I download the program it also says it was created on the 20th July. Is this the latest one?
And as an aside, there is a quote on the front page "bst is an attempt at creating a multi-platform tool suite for developing with the Parallax Propeller". Given the stability and extreme usefulness of this program, I am wondering if it is time to delete the word "attempt" and simply say "bst is a multi-platform tool suite for developing with the Parallax Propeller"?
You don't need a 1 after the string. It's NUL terminated and that should suffice.
Dr_Acula said...
Re pullmoll - can you test it with bst, ie the IDE environment, (not the command line one). Then we at least will be testing on the same software.
After some playing around and trying also BST behaves erratic. I first thought it was better, but this isn't true all the times.
Dr_Acula said...
I still can't seem to get the latest BSTC command line program.
I think I got it from the snapshot directory. It was a build of Dec 2009 IIRC. bstc-0.15.3.linux.zip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Re BST - that really is most strange. Same hardware (I tested that board here many times). Windows. Same BST program. So what is different? The download cable?
Dr_Acula said...
Fixed the ,1 - saved a long too. Thanks for that.
Re BST - that really is most strange. Same hardware (I tested that board here many times). Windows. Same BST program. So what is different? The download cable?
No, I actually believe it has to do with some undefined state of the serial port. I believe this because BSTC works right after once using the Loader.py Python script to upload an EEPROM file. I think that Loader.py leaves the /dev/ttyS0 (= COM1) in a state that makes BSTC work, whereas after running BSTC once, successfully, the second upload will then fail. On the other hand Loader.py fails once after BSTC was successful and succeeds the 2nd, 3rd, ... time. It may have to do with how the DTR line is after the upload. I have to take a look at Loader.py what it does with the serial port. I could change my makefile to call Loader.py (which will fail) before calling BSTC (which will then succeed) to work around the problem for now. Edit: YES!! This awful hack works for me.
So it leaves the DTR low, also after the upload and exit. I could imagine that BST(C) leave it high, which would explain why Loader.py fails the first time after BST(C): There is no change from DTR=1 to DTR=1 and the 0.025s sleep. After the try that fails DTR is then 0 and the 2nd try succeeds. With running Loader.py prior to BSTC I do nothing more but lower DTR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I made an archive on my iMac (10.6.2) today to post to a forum thread and it should have had 2 user spin files and 2 spin files from the main libraries. The result had three empty spin files and one containing what it should have. The problem is quite repeatable. Here is the bogus archive from BST (19.3) and also a hand made archive of what should have been in there.
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden www.wulfden.org/TheShoppe/
Thanks for the report Brian. Due to circumstances beyond my control, my participation in the forum and on bst is pretty much on the skids until the 18th of April. If it can wait until then I'll get it fixed as soon as I can.
Sorry guys, things have been a bit hectic of late.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
hover1 said...
Brad's site seems to be down right now. Here's the latest one I have as of yesterday.
It's back up now. Web server died again.
I'm now off-line until next weekend. It should not crash (it's only the second time in 4 years), but who knows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Brad, I was able to download the linux version, but it's not working [noparse]:([/noparse]
First I got
phenom:/home/jmspaggi/Desktop# ./bst.linux
./bst.linux: error while loading shared libraries: libgdk_pixbuf-2.0.so.0: cannot open shared object file: No such file or directory
BST works fine in Ubuntu 64bit even on the latest 10.04 but it won't run on SimplyMepis 64bit as that's Debian based as well and is missing the same file you are. I did have a quick look for that file but it might have to wait until Brad gets back.
Propeller Tool is happy with this, e.g. repeat -(-10) is equivalent to repeat 10.
Yeah, a bug in the bstc compiler. I've fixed it and will have revised binaries out in the next day or so (as I get back up to speed).
@jmspaggi, I won't be doing any native builds of X86_64 binaries in the near future as I don't possess a machine to test them on. Sorry.
You should be able to install the i386-compat libraries and have it work though. I test all the command line binaries on my server, which is X86_64, but does not have X11 or any other GUI libs installed. (or a monitor/keyboard for that matter).
@Brian Riley. It appears with the changes to pathing I made to accommodate PropBasic, I broke something in the archive function. I'm looking into it now.
<edit>
@jmspaggi, it looks like you need to install ia32-libs-gtk to get the right i386 compat libraries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
There is an oddity with unused method removal. Probably due to there being only one pass (assumption on my part).
VAR
long stack[noparse][[/noparse]100]
PUB main
PUB one
cognew(two, @stack{0})
PRI two
In the source above, public method one gets removed, private method two stays. Removing the reference to the private method (by disabling the cognew) makes two disappear as well. Is there an easy fix or is it something we have to live with? Note, this is not a situation which causes me issues. I just happened to come accross this when I checked something else.
kuroneko said...
There is an oddity with unused method removal. Probably due to there being only one pass (assumption on my part).
VAR
long stack[noparse][[/noparse]100]
PUB main
PUB one
cognew(two, @stack{0})
PRI two
In the source above, public method one gets removed, private method two stays. Removing the reference to the private method (by disabling the cognew) makes two disappear as well. Is there an easy fix or is it something we have to live with? Note, this is not a situation which causes me issues. I just happened to come accross this when I checked something else.
No, that's a bug. The method removal is an iterative process and it gradually peels back the layers on each pass until it can remove no more. If "two" is not being removed after "one" is then it's a bug and I need to fix it. Thanks for the report. I'm a bit manic at the moment what with my partners parents being here from the other hemisphere, so when the dust settles after they fly out tomorrow I have a number of bugs I need to get squashed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Last time I installed 32 bits libs on my system I had to re-install everything [noparse]:([/noparse] Not I will continue to use it inside VirtualBox instead until you get a chance to do a 64bits version.
Let me know if there is anything I can do to help.
On a whim, tried the bst. Enabled the warnings, and what do you know, found a missing #. I think this is a bug I have spent months off and on looking for, so, thanks Brad.
Erik Friesen said...
On a whim, tried the bst. Enabled the warnings, and what do you know, found a missing #. I think this is a bug I have spent months off and on looking for, so, thanks Brad.
No worries, but from memory it's Mike Park who deserves the credit for that one. I think I just copied that warning from Homespun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I've uploaded 0.19.4-pre9. I'm pretty sure I've squashed every bug except the one Brian spotted with the archiving (I've been unable to reproduce it yet).
I've made a pretty significant timing change to the downloader to try and make it closer to the behaviour of the Propeller Tool for people using transistor serial interfaces. I don't have one myself so I don't really know how it will behave. Feedback welcome.
Provided there are no major showstoppers with this one, and I can get the archiving fixed we should be good to go shortly.
<edit> there are a few new bits in here that are not obvious.
After you compile a source file and the symbols become available to the IDE you can select an object (for example tv.str) by clicking on the word "tv". Ctrl-Space gives you a list of exports from that object. Right click gives you a new item at the top of the context menu "Open object under cursor", which does what it says.
The symbols now persist switching tabs, and are only invalidated on a per object basis when any change is made to the source. I'm considering not invalidating them at all so you can just keep working, and use the ctrl-space feature (particularly) to check on the object you are writing a call to without having to move about. This does mean the symbols have the potential to get out of date and must be periodically update with F9, but I think the pro's outweigh the con's.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Downloaded 0.19.4-pre9 - Tested all menu systems - NOT any problems that I had in older ones.
Even Recent files function now with .pbas files.
THANKS
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Downloaded 0.19.4-pre9 - Tested all menu systems - NOT any problems that I had in older ones.
Even Recent files function now with .pbas files.
Yes, there was a bug in the recent files menu, but I've not done anything to deliberately fix the about box issue. It was(is) a bug in the lazarus toolset on Win32 only and it has been particularly evasive. Fingers crossed it stays fixed [noparse]:)[/noparse]
Glad its finally working for you anyway.
Cheers!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
The other bugs are all expected. I'm half way through a nasty code re-factor which affects project files.
Unfortunately I've had other stuff come up, so I'll get a build out soon with all of the IDE changes reverted but with the compiler change implemented which will at least get things reliable again until I get a chance to finish the project file stuff. Look for 0.19.8-Pre8 in the next hour or two.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 12:58:21 PM GMT
bstc -p2 -d COM1 -e -Oa -or Main_Dr_Acula.spin
rem TERATERM.EXE
pause
Works fine but this is on windows, not ubuntu
Version is late November, 2009. I'll see if I can get a more recent version...
Hmm - I can't seem to find any version later than 20th July 2009. I've tried browsing the directories but they keep going round in circles. I'm a bit stuck here.
Addit - scratch that - found a way out of the circles. Downloading now...
Um - no that was the latest version of BST. I can't seem to get the latest version of BSTC.
And now I am stuck because the latest version of BST is not compiling the dracblade. Error on this line:
r:=sd.popen(string("MYNAME.TXT",0),"r")It is expecting a value of "1 to 255" where there is the 0.
I tried a value of 1 and that didn't work either. I have gone back to the 15th Jan version for the moment as that works fine. Has the syntax changed in the last couple of months?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/19/2010 1:15:12 PM GMT
@Dr_A, yes recently a "0" in a String() construct has recently been outlawed as the Parallax compiler considers it invalid (Thanks kuroneko). String() null terminates anyway.
I just tried ...
PUB Fred | X X := String("MYNAME.TXT",1).. on 0.19.4-pre8 and it compiles fine. Can you attach the code that is choking so I can reproduce it locally please?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I had enabled the "High speed Propeller Download / Detect" in bst.linux. If bstc uses the 115k2 baud, then this works not (as good) compared to bst's high speed mode. Actually it didn't seem to make a difference if I check high speed or not. bst manages to upload to RAM most of the times, while bstc doesn't. Edit: Now, after trying a few more times, bst doesn't upload in either high or low speed. The whole story seems to behave very erratic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 10:20:39 PM GMT
Thanks for that - I thought I was going a bit crazy. Ok, changed to 1, files recompiled and now work with the latest bst program. Also new zip on the dracblade thread (post1), and a direct link to the bstc download page in case this thread gets hard to find.
Ok, 115 works but the faster option does not. (I am still not sure how you get 115k to work, as the fastest I ever got a N8VEM working reliably was 38k, above that some bytes started getting corrupted, and that uses the same uart chips that are in a PC. All a bit of a mystery. I suspect my ribbon cable is too long - 3 metres. But it still doesn't explain how the BST program manages 115k).
Re pullmoll - can you test it with bst, ie the IDE environment, (not the command line one). Then we at least will be testing on the same software.
I still can't seem to get the latest BSTC command line program. If I go to this page www.fnarfbargle.com/bst.html and to the link bstc down the bottom the date says 20th July, and if I download the program it also says it was created on the 20th July. Is this the latest one?
And as an aside, there is a quote on the front page "bst is an attempt at creating a multi-platform tool suite for developing with the Parallax Propeller". Given the stability and extreme usefulness of this program, I am wondering if it is time to delete the word "attempt" and simply say "bst is a multi-platform tool suite for developing with the Parallax Propeller"?
Just a suggestion!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
After some playing around and trying also BST behaves erratic. I first thought it was better, but this isn't true all the times.
I think I got it from the snapshot directory. It was a build of Dec 2009 IIRC. bstc-0.15.3.linux.zip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 1:27:17 AM GMT
Re BST - that really is most strange. Same hardware (I tested that board here many times). Windows. Same BST program. So what is different? The download cable?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
No, I actually believe it has to do with some undefined state of the serial port. I believe this because BSTC works right after once using the Loader.py Python script to upload an EEPROM file. I think that Loader.py leaves the /dev/ttyS0 (= COM1) in a state that makes BSTC work, whereas after running BSTC once, successfully, the second upload will then fail. On the other hand Loader.py fails once after BSTC was successful and succeeds the 2nd, 3rd, ... time. It may have to do with how the DTR line is after the upload. I have to take a look at Loader.py what it does with the serial port. I could change my makefile to call Loader.py (which will fail) before calling BSTC (which will then succeed) to work around the problem for now. Edit: YES!! This awful hack works for me.
Edit: Here's Loader.py's reset function:
def reset(self): self.serial.flushOutput() self.serial.setDTR(1) time.sleep(0.025) self.serial.setDTR(0) time.sleep(0.090) self.serial.flushInput()So it leaves the DTR low, also after the upload and exit. I could imagine that BST(C) leave it high, which would explain why Loader.py fails the first time after BST(C): There is no change from DTR=1 to DTR=1 and the 0.025s sleep. After the try that fails DTR is then 0 and the 2nd try succeeds. With running Loader.py prior to BSTC I do nothing more but lower DTR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 1:41:38 AM GMT
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
Sorry guys, things have been a bit hectic of late.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Thanks,
JM
Jim
Note: Windows Version
It's back up now. Web server died again.
I'm now off-line until next weekend. It should not crash (it's only the second time in 4 years), but who knows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Brad, I was able to download the linux version, but it's not working [noparse]:([/noparse]
First I got
and also
When I tried to copy the lib in the current folder [noparse]:([/noparse]
I'm running Debian AMD64. Maybe that's why? Do you have an AMD64 version available? I can compile and test it if you want.
Thanks,
JM
Update: Just tried with VirtualBox and a 32 bits Debian version, and it's working fine. So hope you will be able to compile it for 64bits...
Message Edité (jmspaggi) : 4/11/2010 2:42:07 AM GMT
Propeller Tool is happy with this, e.g. repeat -(-10) is equivalent to repeat 10.
BST works fine in Ubuntu 64bit even on the latest 10.04 but it won't run on SimplyMepis 64bit as that's Debian based as well and is missing the same file you are. I did have a quick look for that file but it might have to wait until Brad gets back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Yeah, a bug in the bstc compiler. I've fixed it and will have revised binaries out in the next day or so (as I get back up to speed).
@jmspaggi, I won't be doing any native builds of X86_64 binaries in the near future as I don't possess a machine to test them on. Sorry.
You should be able to install the i386-compat libraries and have it work though. I test all the command line binaries on my server, which is X86_64, but does not have X11 or any other GUI libs installed. (or a monitor/keyboard for that matter).
@Brian Riley. It appears with the changes to pathing I made to accommodate PropBasic, I broke something in the archive function. I'm looking into it now.
<edit>
@jmspaggi, it looks like you need to install ia32-libs-gtk to get the right i386 compat libraries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 4/14/2010 10:31:53 AM GMT
VAR long stack[noparse][[/noparse]100] PUB main PUB one cognew(two, @stack{0}) PRI twoIn the source above, public method one gets removed, private method two stays. Removing the reference to the private method (by disabling the cognew) makes two disappear as well. Is there an easy fix or is it something we have to live with? Note, this is not a situation which causes me issues. I just happened to come accross this when I checked something else.
No, that's a bug. The method removal is an iterative process and it gradually peels back the layers on each pass until it can remove no more. If "two" is not being removed after "one" is then it's a bug and I need to fix it. Thanks for the report. I'm a bit manic at the moment what with my partners parents being here from the other hemisphere, so when the dust settles after they fly out tomorrow I have a number of bugs I need to get squashed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I can run the testing for the 64bits if you want?
Last time I installed 32 bits libs on my system I had to re-install everything [noparse]:([/noparse] Not I will continue to use it inside VirtualBox instead until you get a chance to do a 64bits version.
Let me know if there is anything I can do to help.
Thanks,
JM
No worries, but from memory it's Mike Park who deserves the credit for that one. I think I just copied that warning from Homespun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I've made a pretty significant timing change to the downloader to try and make it closer to the behaviour of the Propeller Tool for people using transistor serial interfaces. I don't have one myself so I don't really know how it will behave. Feedback welcome.
Provided there are no major showstoppers with this one, and I can get the archiving fixed we should be good to go shortly.
<edit> there are a few new bits in here that are not obvious.
After you compile a source file and the symbols become available to the IDE you can select an object (for example tv.str) by clicking on the word "tv". Ctrl-Space gives you a list of exports from that object. Right click gives you a new item at the top of the context menu "Open object under cursor", which does what it says.
The symbols now persist switching tabs, and are only invalidated on a per object basis when any change is made to the source. I'm considering not invalidating them at all so you can just keep working, and use the ctrl-space feature (particularly) to check on the object you are writing a call to without having to move about. This does mean the symbols have the potential to get out of date and must be periodically update with F9, but I think the pro's outweigh the con's.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 4/20/2010 8:02:44 AM GMT
Downloaded 0.19.4-pre9 - Tested all menu systems - NOT any problems that I had in older ones.
Even Recent files function now with .pbas files.
THANKS
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Yes, there was a bug in the recent files menu, but I've not done anything to deliberately fix the about box issue. It was(is) a bug in the lazarus toolset on Win32 only and it has been particularly evasive. Fingers crossed it stays fixed [noparse]:)[/noparse]
Glad its finally working for you anyway.
Cheers!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Where is the file?
In http://www.fnarfbargle.com/bst/Latest/ I only have
I want to retry with the 64b version.
Thanks,
JM