The main purposes of this release is to improve the installer, and make a few minor improvements to the windows registry functions, associations, and run/launch. We want to make REBOL work better on newer versions of that OS.
This is also a "window" for fixing other critical bugs. But, the window isn't wide, so submit it as a fix or as a reproducible bug. There's no time for mystery bug investigation.
You can post your fixes in R3 Chat #7069 (R2/Releases/R2.7.8) or in the comments area below.
Brian Hawley
19-Mar-2010 14:53:53 |
Some comments:
- The rest of the R2/Forward mezzanine fixes and enhancements have already been posted. They're current as of alpha 80 compatibility (no modules yet).
- Windows XP also has %appdata% - it's Win9x that doesn't. And for Win9x you can use the same registry equivalent as later Windows.
- A lot of installers on Windows provide an "Install for all users" option, and only require administrative privileges if the option is checked. Otherwise the program and its settings are installed in user-specific locations of the registry and filesystem. This would be a good model for R2 to follow.
- There should be a way to specify that the /View exe should run in place without offering to install; perhaps a setting in %rebol.r ? This will allow portable app usage.
- The registry also allows binary and integer values, not just strings. Perhaps these could be supported too, based on the REBOL datatype used.
Also, is there anything inherent in the implementation of SSL and ODBC that requires the /View event model or something? Can they be ported to /Pro eventually? |
Maarten
20-Mar-2010 1:37:43 |
R2 forward docs!!!
Also, does os x intel have the library interface these days! |
Gabriele
20-Mar-2010 3:25:14 |
There appears to be a bug with AS-STRING (or, the GC, or the something weird happening with the encryption ports) in 2.7.6. I haven't tested 2.7.7 yet.
Workaround I had to use in Hardball |
Carl Sassenrath
20-Mar-2010 8:37:24 |
Brian, thanks for that list.
In addition, we need to determine which R2/Forward funcs are integrated at the mezz core during boot (e.g. /base and /encap) and which are in the mezz upper layer. We want to minimize what's part of the core for SDK users, as we do for the other mezz functions. |
Carl Sassenrath
20-Mar-2010 8:49:53 |
Gabriele: I'd have to believe it's in the port. (A bug in AS-STRING itself is less likely.) We've seen this kind of problem before, such as the clipboard port.
BTW, I looked at your code, but it's not obvious what kind of simple test to do on this. Unless it can be isolated and reproduced, it won't get fixed in this release. |
onetom
21-Mar-2010 14:27:36 |
On REBOL/Core 2.7.7.2.5 (5-Jan-2010) Intel OS X 10.6.2 the following snippet segfaults after a few seconds and the open command doesn't even returns a prompt.
system/ports/serial: [tty.usbserial-A3000PZa]
p: open/direct/no-wait/binary serial://port0/38400/8/none/1
I tried an Arduino board and a plain FTDI chip which was connected to a PIC controller. Both worked via the screen command like this:
screen /dev/tty.usbserial-A3000PZa 38400
screen /dev/tty.usbserial-A8008FSa 9600
I have the latest driver for the USB serial converter from
ftdichip.com
Anyone any experience/idea? Can anyone confirm the problem pls?
This small thing is VERY important actually, because opens up REBOL for the electronics and embedded computer professionals in a CROSS PLATFORM way!
My father is already using it for creating virtual test instruments/panels when he is fixing or replacing parts of Caterpillar machine electronics and he uses it for creating experimental devices for biological and healthcare research institutes in Europe (Hungary) too.
I would like to promote this kind of setup (FlashForth in PIC + REBOL on personal computer) in Asia too, but many ppl have Macs too (in Singapore and Japan at least).
We are organizing a Barcamp in Singapore by the next weekend and it's a pity I cannot showcase it on a Mac.. ;(
|
onetom
22-Mar-2010 1:38:29 |
... serial://port1/...
is the correct code above. |
onetom
22-Mar-2010 1:39:35 |
which causes the segfault, i mean. |
Carl Sassenrath
24-Mar-2010 15:56:35 |
The serial port code was tested mainly under Linux systems, so BSD (OS X) could be different in some ways. I'll take a quick look at it. If it's not obvious, I can upload the relevant source serial port source code if someone wants to take a crack at it. |
Brian Hawley
24-Mar-2010 18:10:45 |
Sunanda reported a problem in extract in R3 that would also apply to R2. I'll post the fix to DevBase, and for R3 as well. |
Brian Hawley
24-Mar-2010 23:04:29 |
As for which of the R2/Forward functions to put into /Base, that's a bit of a question. I was surprised to find out how many mezzanines were in /Base already, including some that really don't seem to need to be there (alter, in-dir and to-relative-file come to mind).
As for the R2/Forward additions, I would say that these should be added to /Base: cause-error, throw-error, funct, closure, closure!, to-closure, to-function, !, ++, --, also, true?, first+, ajoin, collect, move, swap, take, and undirize (because dirize is there). I'm not sure about the string functions but you might consider them worth including in /Base: ascii?, latin1?, utf?, invalid-utf?, deline and enline.
Some functions should be backported as natives: apply, assert, map-each, resolve and unbind. Until that happens, the mezzanine versions should be included in /Base. There isn't a mezzanine for unbind yet though; it's a hard problem to do in mezzanine.
It would be up to you if you want to include the reflection functions and typeset stuff: *-of, reflect, typeset!, typeset? and to-typeset. The advantage is that these are much safer to use than the R2 native reflection, and we want to encourage their use instead of the overloaded ordinals. The disadvantage is that some of these functions are large, particularly to-typeset and types-of. In any case, the SDK should include this stuff. The rest of the fake typeset stuff should be in the SDK but doesn't need to be in /Base. |
Paul
26-Mar-2010 4:46:12 |
Oh were talking /Base. I don't think we should include any new mezzanines into /Base. Base should be lean as can be. If you got fixes for existing mezzanines in /Base then include those. Better to offer the R2/Forward as a separate download (bonus pack). |
Brian Hawley
26-Mar-2010 15:28:16 |
Most of the functions in R2/Forward provide basic functionality, and are all backports from R3. I agree that it would be interesting to have a really minimal REBOL build, but looking back on previous SDK releases that is not really what /Base has been.
/Base already has functions in it that are less important than most of the ones listed above (including many of the natives). /Base has a lot of the core mezzanines, but not the schemes or online help. I guess they expect you to actually be able to get stuff done in /Base directly, rather than requiring an encap for every app.
Should we revisit the purpose of /Base? Do we have a need for a real minimal REBOL? |
Brian Hawley
26-Mar-2010 15:55:43 |
Note: The apply mezzanine uses quote, so that's a dependency if you don't make apply native. And you should decide whether your single? function should make the /Base cut, Carl.
The collect-words function from R2/Forward is a backport of a internal function used by make object!, that was made available as a native function in R3. If there is a similar internal function in R2's make object!, perhaps it could get externalized as well, replacing the much slower mezzanine. |
Ingo
27-Mar-2010 12:00:10 |
I often use Rebol from a USB stick, or as a quick toolbox. Just fire it up and do some stuff.
So, for me it is important to be able to run it without installation. (And I normally don't use the viewtop / *-thru functions. Though I use the *-thru functions on my installed machine.)
|
Mark Ingram
29-Mar-2010 7:52:57 |
I do not even know if this is officially a bug, but I would like to put in a call for what is a critical fix for me, namely, an option to :random to return the internal state of the random number generator (i.e., what seed value to set on a future invocation of REBOL so as to have the same state as the current invocation). |
David den Haring
5-Apr-2010 12:42:07 |
The BROWSE function doesn't work in Linux.
Since CALL is now included in REBOL/View, I wonder if BROWSE should become a mezzanine function.
|
Brian Hawley
11-Apr-2010 17:41:23 |
David, browse can't be a mezzanine without putting platform-specific stuff into mezzanine code - distro-, system- or user-specific in the Linux case. In the Windows case it depends on access to the registry, which non-SDK mezzanine code can't without calling an external program (reg.exe).
As a rule, platform-specific stuff is not supposed to go in the mezzanine code. And user-specific stuff goes in %rebol.r or some such, which can easile contain an overriden browse if you like that calls your preferred browser.
Still, it would be a good idea to see if there is currently some reasonably commonly adopted way that Linux distributions specify what the user's preferred browser is, and call that by default. At the time that browse was written no such standard existed, and it wouldn't be likely to be adopted beyond the major distros now if it currently exists. And that would still need to fall back to something we can insist on, like an environment variable, for distros that don't follow the common practice. |
Oldes
14-Apr-2010 8:39:47 |
If there is something missing, than it's Linux Core version with library support enabled. It's free in Windows version for a very long time already. |
Oldes
15-Apr-2010 17:05:20 |
There seems to be inconsistency between Linux and Windows
Let's have routine like:
MagickWriteImages: make routine! [
"Writes an image to the specified filename."
*wand [integer!]
filename [string! ]
return: [integer!]
] lib_ImageMagickWand "MagickWriteImages"
Then under Windows it's possible to write:
MagickWriteImages *wand to-local-file rejoin [what-dir somefile]
but under linux the above throws error like:
** Script Error : Expected one of: pic/0/ - not: string
** Where: do
** Near: [MagickWriteImages *wand to-local-file rejoin]
And works only:
tmp: to-local-file rejoin [what-dir somefile]
MagickWriteImages *wand tmp
But I'm not sure if it's easy fixable. |
alberto
13-May-2010 17:19:08 |
from R3 chat:
2.7.7 Was supposed to have the 'library DLL access components, but only View has it, not Core, at least on Linux. Can this be fixed? -- Kaj
Or added in 2.7.8 core for linux? |
Izkata
15-Jul-2010 17:52:31 |
Late, but I just ran across this. Not sure where else to put it.
In linux, in 2.7.7, the 'vectorial argument to 'text in the draw dialect causes a segfault, as does any word! values not part of the dialect. For example, both of these work fine in 2.7.6, but not in 2.7.7:
view layout [box effect [draw [pen white]]]
view layout [box 100x100 effect [draw [text vectorial 0x0 50x50 100x100 {Test}]]]
The second one would display nothing in linux as font is not set - but that then triggers both the causes if done this way:
TextFont: make face/font [name: {/usr/share/fonts/truetype/freefont/FreeSans.ttf}]
view layout [box 100x100 effect [draw [font TextFont text vectorial 0x0 50x50 100x100 {Test}]]] |
Maarten
31-Oct-2010 5:52:16 |
Two major ones:
meez-sppor and mezz-reflect are not included in the distro, but are requuired by mezz.r
An encapped view app on OS X gives a terminal window. Can we make that disappear - think App stores... |
Endo
2-Dec-2010 0:16:55 |
"There should be a way to specify that the /View exe should run in place without offering to install; perhaps a setting in %rebol.r ? This will allow portable app usage."
I agree, it pops up installer window for each different user. and no option to install for everyone (systemwide, holding %user.r file in %windows% dir.)
I prefer --install command line argument instead of --no-install, and start in console with a help string "type desktop or install".
|
Nicolas V. (nve)
21-Dec-2010 23:25:47 |
And what is the effort to port the design made in march 2010 for R3/VID ?
http://www.rebol.com/r3/docs/gui/guide.html
Looks very very nice and modern !
Please make a refresh of R2 !
|
Nicolas V. (nve)
21-Dec-2010 23:26:47 |
R3 GUI User's Guide |
You can post a comment here. Keep it on-topic.
