@dgately: thanks. I think actually the regular Makefile should now work for the Mac too (so plain "make install" should work on macosx, at least if you have gcc installed).
Thanks... make install does seem to work as it should now! I always have Xcode installed, thus gcc is always available. Anyone wishing to compile code on macOS should also install Xcode, just to get all the developer utilities.
On the MAC (with Yosemite) the default xterm method in the run command fires up the Quartz X environment which retains focus after you close the xterm or when the xterm shuts down if you hit enter or ^] so you need to go back to the mouse to reclick the flexgui window before you can type again.
I found I had to put in a special command in my own script that would at least refocus the flexgui window afterwards. I'm basically adding in this custom stuff because the default TCL/TK + flexgui behaviour is not really keyboard optimized on the MAC (for my usage preferences anyway).
I have these two scripts in the flexgui top folder.
wish.sh:
#!/bin/bash
osascript -e 'tell application "Wish" to activate' > /dev/null
The flexgui run command is set to this, and with my gui.tcl hacks the extra %T is now either translated to "-t" or " " depending on which button/hotkey you pressed, Command-R (run no terminal) or Command-T (run with terminal).
I'm trying to make random numbers in the 1080p range like this:
x:=?x**1920
y:=?y**1080
This doesn't really work because the result can be negative... Kind of an issue with spin being always signed...
Well, I searched and found some code by Phil that leads me to this:
fastspin maintains backwards compatibility with Spin1, so the ? operator works the same (using the same LFSR). To use getrnd you can do something like:
pub myrnd : r
asm
getrnd r
endasm
Of course if you're using fastspin you can also use the C library, which has a _randbits function:
pub file "libsys/random.c" _randbits
...
x := _randbits +// 1920 ' generate number between 0 and 1919
_randbits uses getrnd on P2 and the old LFSR on P1, and always returns a non-negative number.
Also note that there are some unsigned operations in fastspin: unsigned divide and remainder "+/" and "+//", and unsigned comparisons "+>", "+<", etc. I think Chip is planning on implementing those in his Spin2 interpreter as well.
FastSpin seems to letting me declare routines with same name twice without giving an error:
'Spin2 colorizer test
CON 'Constants section
DAT 'Dat section
PUB main
PUB main
Yes indeed... that code should have produced a warning (the two definitions of main were the same so they could be combined) and code with different function definitions should provide an error. There's a typo in the check for that though and the error wasn't being caught. I'll fix that in the next version of fastspin.
ersmith: I hope you are enjoying your Thanksgiving and not reading this
Thanks, but where I live we celebrated Thanksgiving back in October, I guess because our growing season is much shorter . But I hope you're enjoying it.
But, I'll mention, before I forget...
Seems there's an issue with inline assembly.
I have this routine for random number generation:
PUB RND(x)|r 'return random integer between 0 and x
asm
getrnd r
mul x,r
shr x,#16
endasm
return x
This worked fine, until there was more code added to program. Now, I get this (see image):
I'm curious, what makes you think it's a problem with the inline assembly? You may be right, but I'm actually suspecting something else (a problem with optimization).
If you get a chance, could you try out the fastspin.exe from the attached zip? If I'm right it should fix your problem. If I'm wrong, are you able to share the code that's triggering the bug?
Just found something else that looks like a bug...
It doesn't like me using "pb" or "pr" as a variable:
PUB Demo2|x,y,cx,cy,ex,ey,r,g,b,px,py,pr,pb,pg,n,i 'Moving curve
'create random points
n:=1000
px:=@xpoints
py:=@ypoints
repeat i from 0 to n
long[px][i]:=RND(1920)
long[py][i]:=RND(1080)
'create random colors
pr:=@rl
pb:=@bl
pg:=@gl
Does the C in FlexGUI still support P1?
I was just looking at the samples and they all look like P2...
Yes, all of the compilers still support P1; under the hood they are all basically the same compiler (the differences between C, BASIC, and Spin are almost all syntactic, with just a few little language specific tweaks).
I've been more focused on P2 lately so more of the examples are coming from that direction, that's all.
I've made some changes recently to the Tcl scripts to make them work better (I hope) on Mac OS. If you tend to use a Mac, and are able to build flexgui from source, I'd be interested in hearing your feedback.
Thanks so much for providing FlexGUI and FastSPIN, ersmith, as well as updating them.
Speaking of updating, I was having a little problem with FlexGUI V4.0.3 reverting back to the P1 (from the P2b) when I rebooted. That caused things like "hubset #0" to be flagged, which caused me to scratch my head for a minute until I figured out what was going on. But I just installed V4.0.4 and FlexGUI appears to retain the processor setting just fine (Well, at least it stayed on the P2b setting for me across a reboot). Thanks.
I did notice one small thing in using FlexGUI over the last few days since I got my first P2 board to play with. And it's a very low-priority or non-critical thing, but for what it's worth: If I reuse a constant name (inadvertently or in debugging), the compile doesn't fail or provide a warning, and it uses the first instance of the name. So, for example, if I say:
CON
basepin = 32
basepin = 24
...the program will compile with the first value (32), unless I comment its line out, of course.
Obviously, it doesn't make sense to give a constant multiple values, but sometimes I've done so while debugging, thinking that the last declaration would win out. It doesn't. But I don't think that's important, and maybe managing the namespace is tedious enough as it is.
However, of much more interest to me would be if the font size in the Compiler Output window at the bottom of the screen could be adjusted (made larger). On a 14" laptap and with my ageing eyes, I often have to resort to a magnifying glass to read the output.
Anyway, minor stuff. And thanks again for all your amazing work. --Jim
I've made some changes recently to the Tcl scripts to make them work better (I hope) on Mac OS. If you tend to use a Mac, and are able to build flexgui from source, I'd be interested in hearing your feedback.
make install appears to work, leaving a new flexgui directory at the user's root... Exec'ing wish flexgui.tcl inside that directory runs flexgui, successfully.
make install responds with an error as it cannot find "<tk.h>"... That file does exist at "/Library/Frameworks/Tk.framework/Headers", but that directory is not in $PATH originally and is not found without edits.
I've made some changes recently to the Tcl scripts to make them work better (I hope) on Mac OS. If you tend to use a Mac, and are able to build flexgui from source, I'd be interested in hearing your feedback.
make install appears to work, leaving a new flexgui directory at the user's root... Exec'ing wish flexgui.tcl inside that directory runs flexgui, successfully.
make install responds with an error as it cannot find "<tk.h>"... That file does exist at "/Library/Frameworks/Tk.framework/Headers", but that directory is not in $PATH originally and is not found without edits.
I'm guessing that it's "make zip" that has the error? If so then that's OK, the only reason to do "make zip" is to build a Windows distribution and you'd need a cross compiler and Windows version of Tcl/Tk. I'll make that clearer in the Makefile.
I did notice one small thing in using FlexGUI over the last few days since I got my first P2 board to play with. And it's a very low-priority or non-critical thing, but for what it's worth: If I reuse a constant name (inadvertently or in debugging), the compile doesn't fail or provide a warning, and it uses the first instance of the name. So, for example, if I say:
CON
basepin = 32
basepin = 24
...the program will compile with the first value (32), unless I comment its line out, of course.
Ouch. That's definitely a bug, and I'll look into it. Thanks for catching this!
However, of much more interest to me would be if the font size in the Compiler Output window at the bottom of the screen could be adjusted (made larger). On a 14" laptap and with my ageing eyes, I often have to resort to a magnifying glass to read the output.
I've been meaning to add a dialog box for changing the "Compiler Output" font. For now you can adjust it manually by editing the src/gui.tcl file. There's a line like:
Thanks, ersmith! I changed the font size as you mentioned, and now it's bigger. That's kind of a weird font; it appears to be a bit-mapped font rather than a vector font, as it gets kind of "jagged" as it gets larger. But I can make it out better at a larger size and don't need to use a magnifying glass, so I'm pleased. Thanks for your assistance. --Jim
I build loadp2.exe myself from source on a Linux machine using a cross-compiler, so it's extremely unlikely indeed to be infected with a Windows virus.
I haven't been signing loadp2.exe (just fastspin.exe and flexgui.exe); I guess I should probably start signing loadp2.exe as well to prevent later infection once installed on a user's computer.
There is a new release of FlexGUI (4.0.5) containing updated versions of fastspin and loadp2. Notable improvements are:
(1) It is now possible to load the python interpreter and a (small?) script directly from the Specials menu. I haven't tried very large python files, but simple things like the blinking demos in the samples/upython directory work fine.
(2) The version of micropython included now supports running (binary) PASM code in other COGs.
(3) There is a file server built in to the loadp2 program now, so programs on the P2 can read and write files on the PC. This is still under development, so it's not well integrated with the host languages yet (you can't just use fopen() in C, for example ) but that will come. For now see the examples under samples/fileserver. There are 3 example programs: ls.spin (list a directory on the PC), test9fs.c (read a file from the PC) and writer.bas (write a file to the PC).
(4) There are various improvements to the fastspin compiler. Most of them are bug fixes, but one new warning may be of interest: if you try to use an integer constant without a # in front of it the compiler will print a warning. This is only a warning, since it is technically legal. You can get rid of the warning by adding "+0" or "-0" after the constant, so the traditional 0-0 placeholder does not produce the warning.
(5) The Lisp interpreter is built by default, and can be run from Specials like micropython is.
Comments
dgately
I found I had to put in a special command in my own script that would at least refocus the flexgui window afterwards. I'm basically adding in this custom stuff because the default TCL/TK + flexgui behaviour is not really keyboard optimized on the MAC (for my usage preferences anyway).
I have these two scripts in the flexgui top folder.
wish.sh:
terminal.sh:
The flexgui run command is set to this, and with my gui.tcl hacks the extra %T is now either translated to "-t" or " " depending on which button/hotkey you pressed, Command-R (run no terminal) or Command-T (run with terminal).
Does the ? operator work the same as P1, or is it using the new GETRND instruction?
Anyway, how can I use the GETRND instruction in Spin2? Do I need an ASM block?
This doesn't really work because the result can be negative... Kind of an issue with spin being always signed...
Well, I searched and found some code by Phil that leads me to this:
It's ugly, but maybe works...
pub myrnd : r asm getrnd r endasmOf course if you're using fastspin you can also use the C library, which has a _randbits function: _randbits uses getrnd on P2 and the old LFSR on P1, and always returns a non-negative number.
Also note that there are some unsigned operations in fastspin: unsigned divide and remainder "+/" and "+//", and unsigned comparisons "+>", "+<", etc. I think Chip is planning on implementing those in his Spin2 interpreter as well.
PUB RND(x)|r 'return random integer between 0 and x asm getrnd r 'sca r,x 'mov x,x mul x,r shr x,#16 endasm return xNot sure why SCA/MOV doesn't work...
Yes indeed... that code should have produced a warning (the two definitions of main were the same so they could be combined) and code with different function definitions should provide an error. There's a typo in the check for that though and the error wasn't being caught. I'll fix that in the next version of fastspin.
Thanks for the bug report!
But, I'll mention, before I forget...
Seems there's an issue with inline assembly.
I have this routine for random number generation:
PUB RND(x)|r 'return random integer between 0 and x asm getrnd r mul x,r shr x,#16 endasm return xThis worked fine, until there was more code added to program. Now, I get this (see image):I'm curious, what makes you think it's a problem with the inline assembly? You may be right, but I'm actually suspecting something else (a problem with optimization).
If you get a chance, could you try out the fastspin.exe from the attached zip? If I'm right it should fix your problem. If I'm wrong, are you able to share the code that's triggering the bug?
Thanks,
Eric
It doesn't like me using "pb" or "pr" as a variable:
PUB Demo2|x,y,cx,cy,ex,ey,r,g,b,px,py,pr,pb,pg,n,i 'Moving curve 'create random points n:=1000 px:=@xpoints py:=@ypoints repeat i from 0 to n long[px][i]:=RND(1920) long[py][i]:=RND(1080) 'create random colors pr:=@rl pb:=@bl pg:=@glI don't see any problem with "pr".
See attached... The first value "long[px][0]" comes out wrong... Appears to be more like what long[dx][0] might be...
It should be >200, but that very first value comes out wrong...
Also, the position of these lines seems to matter:
If I put them at the end, it gets all messed up...
I was just looking at the samples and they all look like P2...
Yes, all of the compilers still support P1; under the hood they are all basically the same compiler (the differences between C, BASIC, and Spin are almost all syntactic, with just a few little language specific tweaks).
I've been more focused on P2 lately so more of the examples are coming from that direction, that's all.
Speaking of updating, I was having a little problem with FlexGUI V4.0.3 reverting back to the P1 (from the P2b) when I rebooted. That caused things like "hubset #0" to be flagged, which caused me to scratch my head for a minute until I figured out what was going on. But I just installed V4.0.4 and FlexGUI appears to retain the processor setting just fine (Well, at least it stayed on the P2b setting for me across a reboot). Thanks.
I did notice one small thing in using FlexGUI over the last few days since I got my first P2 board to play with. And it's a very low-priority or non-critical thing, but for what it's worth: If I reuse a constant name (inadvertently or in debugging), the compile doesn't fail or provide a warning, and it uses the first instance of the name. So, for example, if I say:
CON basepin = 32 basepin = 24...the program will compile with the first value (32), unless I comment its line out, of course.
Obviously, it doesn't make sense to give a constant multiple values, but sometimes I've done so while debugging, thinking that the last declaration would win out. It doesn't. But I don't think that's important, and maybe managing the namespace is tedious enough as it is.
However, of much more interest to me would be if the font size in the Compiler Output window at the bottom of the screen could be adjusted (made larger). On a 14" laptap and with my ageing eyes, I often have to resort to a magnifying glass to read the output.
Anyway, minor stuff. And thanks again for all your amazing work. --Jim
make install responds with an error as it cannot find "<tk.h>"... That file does exist at "/Library/Frameworks/Tk.framework/Headers", but that directory is not in $PATH originally and is not found without edits.
dgately
I'm guessing that it's "make zip" that has the error? If so then that's OK, the only reason to do "make zip" is to build a Windows distribution and you'd need a cross compiler and Windows version of Tcl/Tk. I'll make that clearer in the Makefile.
Thanks,
Eric
I've been meaning to add a dialog box for changing the "Compiler Output" font. For now you can adjust it manually by editing the src/gui.tcl file. There's a line like:
text .p.bot.txt -wrap none -xscroll {.p.bot.h set} -yscroll {.p.bot.v set} -height 10 -font "courier 8"that creates the compiler output ("bottom") window. You can change the font to "courier 10" or something more suitable there.Thank you for your feedback!
Eric
Thoughts?
-Martin
I haven't been signing loadp2.exe (just fastspin.exe and flexgui.exe); I guess I should probably start signing loadp2.exe as well to prevent later infection once installed on a user's computer.
(1) It is now possible to load the python interpreter and a (small?) script directly from the Specials menu. I haven't tried very large python files, but simple things like the blinking demos in the samples/upython directory work fine.
(2) The version of micropython included now supports running (binary) PASM code in other COGs.
(3) There is a file server built in to the loadp2 program now, so programs on the P2 can read and write files on the PC. This is still under development, so it's not well integrated with the host languages yet (you can't just use fopen() in C, for example
(4) There are various improvements to the fastspin compiler. Most of them are bug fixes, but one new warning may be of interest: if you try to use an integer constant without a # in front of it the compiler will print a warning. This is only a warning, since it is technically legal. You can get rid of the warning by adding "+0" or "-0" after the constant, so the traditional 0-0 placeholder does not produce the warning.
(5) The Lisp interpreter is built by default, and can be run from Specials like micropython is.