AltME groups: search

PARSE is definitely something I wish was more open

I have done a bit of work on a function version of PARSE. Maybe having 
PARSE as a normal REBOL function could help in fixing bugs? My version 
is not quite ready to publish. Are there a set of PARSE tests somewhere, 
that I could test my version against? I would prefer R2 tests to 
start with. I'm doing my own tests, but maybe we have a more complete 
set of tests somewhere, like in the R3-alpha world (I think, was 
the name), where we did a lot of tests on different things.

That's true,  but map! isa bit awkward for just looking up an item 
in a list.....Map! is optimised for retrieving a value associated 
with a key.

While we're at it, the KEEP operation from Topaz would be useful. 
I use PARSE wrapped in COLLECT, calling KEEP in parens, quite a bit.

a bit more clear:

t: "abc56xyz" parse/all t [some [x: non-digit (x: back remove x) 
:x | skip]] head t

These are also a bit strange:
>> parse-csv {"a", "b"}
== ["a" { "b"}]
>> parse-csv { "a" ,"b"}
== [{ "a" } "b"]
>> parse-csv {"a" ,"b"}
== ["a"]

I'm putting LOAD-CSV in the %rebol.r of my dbtools, treating it like 
a mezzanine. That's why I need R2 and R3 versions, because they use 
the same %rebol.r with mostly the same functions. My version is a 
little more forgiving than the RFC above, allowing quotes to appear 
in non-quoted values. I'm making sure that it is exactly as forgiving 
on load as Excel, Access and SQL Server, resulting in exactly the 
same data, spaces and all, because my REBOL scripts at work are drop-in 
replacements for office automation processes. If anything, I don't 
want the loader to do value conversion because those other tools 
have been a bit too presumptuous about that, converting things to 
numbers that weren't meant to be. It's better to do the conversion 
explicitly, based on what you know is supposed to go in that column.

There's an ad-hoc defacto standard, but it's pretty widely supported. 
I admit, the binary support came as a bit of a surprise :)

Geomol, to explain it a bit:
LINE - draws single lines (eve if you specify multiple coords)

SPLINE - draws 'connected' lines but the 'head' and 'tail' is splitted 
(until you specify CLOSED keyword)
POLYGON - always draws 'connected' lines in form of closed shape

cyphre, has the window-to-front fix for OSX from the blog been noticed? 
someone posted a bit of code to eliminate that problem.

well, in a way they do. there is a ctrl, alt and cmd key. on PC keyboards, 
the ctrl key handles things that normally is assigned to the cmd 
key and the ctrl key. this makes it a bit confusing to copy (ctrl-c) 
things from a terminal on a PC keyboard, whereas the mac keyboard 
uses cmd-C to copy. in rebol this means that the ctrl functionality 
in windows should be mapped to cmd on the mac, but if this was to 
be done right, we'd need a /cmd refinement as well.

Well, that depends on the workload for Carl. If they have to test 
R3 stuff in R2.7, I'm fine with that. Besides I suspect that R2 won't 
be going away until at least a year from now. We simply don't know 
whether R3 will be stable enough in its first incarnation for production 
use. R2 is stable enough as long as you stay with smaller and simpler 
things that aren't graphics heavy. I tend to bend that rule a bit. 
:-)

Little bit more playing around, to see if +s was taking ... doesn't 
seem so.
rebol []
probe system/script
change-dir %..
list-dir
ask "waiting"

c:\tools\rebol\appdata\rebview +s testing.r

...
    words: none
]
waiting

** Script Error: list-dir expected dir argument of type: file url 
unset
** Near: list-dir
ask "waiting"
>>

The ask is evaluated before the list-dir error     And if  list-dir 
%.  is used, it lists the dir, without a security box.

I have an old View 1.3.2 here on Ubuntu where echo takes a bit over 
100 ms, so the bigger delay may be a recent regression

32 bit programs can't write to the windows 64 bit registry

Graham, I noticed it, when I was wondering why a simple two-button 
UI program with a bit of rugby networking ate up 500 MB RAM.

Btw.. he was wrong about using Xon/Xoff instead or HW handshake.. 
 those are used even today  and If I had to choose one Id' definitley 
go hardware. keeps the serial line pure 8.bit, and workd more reliable 
on multitasking PC:s...

Joanna, there aren't a lot of docs on serial ports, but the basics 
are easy enough.


; port speed data-bits parity stop-bit (order is not significant 
IIRC)
port-spec: serial://port2/38400/8/none/1

p: open/no-wait port-spec

p/rts-cts: off  ; THIS IS REQUIRED TO TURN OFF HARDWARE HANDSHAKING!
update p

Then you can just INSERT and COPY on the port.

That was a 2.7.6 change Graham. It bit me, so watch out.

The app I'm building now requires RebGUI and so I get to know it 
a little bit.

I still have 2.3.0 for Win32 lying around, but the Linux versions 
seem to have vanished into bit nirvana :)

amazing with so many different versions for a little bit of image 
processing...

I use CONVERT quite a bit, and it works well for me.

And I really need it for the next bit.

I think I'd rather see a 64 bit release of R2 than a R3 release now.

On 64 bit: really? Why?

Because Windows 2008 server is a 64 bit platform and I can't read 
the registry anymore

32bit applications can not read the 64 bit registry

I'm not familiar with changes MS has made to make the OS 64 bit. 
 Does this change apply to all API functions?

I can understand changing various data-related APIs to allow 64 bits, 
but in general, 64 bit systems are just marketing ploys.

I think it's part of the virtualization stuff that 2008 does to make 
the 32 bit app think it is running under a 32bit os.

I setup a Windows 2008 server on Amazon.  Setup Firebird 64 bit and 
a DSN.  Then tried to connect using ODBC.  Failed.

Also, my client app under W64 (7/vista) can not read the registry 
either ...to see if certain 64 bit apps are installed ( Ghostscript 
etc )

So, any possibility of a 64 bit release of R2?

Easy enough to check if you have a 64 bit windows available

Seems to me that 64 bit windows is now standard for many manufacturers 
like HP

Do you have access to any Windows 64 bit PCs?

There are not any registry calls in the ODBC port.  But, it's always 
been a little-bit version sensitive.

I'm not too concerned about this in view of this work round, but 
I would like a way rebol to access the 64 bit registry if it's just 
a flag setting ...

Just have to rewrite my installer to switch to creating a dsnless 
connection if it detects running on 64 bit windows

I found that OpenSolaris is awfully slow even when compared to slow 
Linux distributions like Ubuntu but that may be just my computer 
since OpenSolaris doesn't support that much hardware. Booting it 
took 10 minutes already but the whole system felt very sluggish. 
Some of the features it has are really nice though. The ZFS video 
where some guy used a big hammer to destroy running harddrives to 
show off ZFS handling it without any problems was cool :) What I 
would like to see Rebol run on is Haiku, especially since you develop 
native apps for it with C++ which usually is quite horrible although 
I have to say that the BeOS api makes C++ programming quite a bit 
less horrible.

Yeah there is a Rebol/Core 2.5.0.5.2 and a Rebol/View 1.2.1.5.2 for 
BeOS R5. I tried the one with View on the latest nightly build of 
Haiku yesterday, didn't work though, some error message about the 
Media Server Addon IIRC. Could be because I used the GCC4 hybrid 
iso, don't know how far they are with that stuff yet, I haven't followed 
the mailing list for a few months. A R3 port in a few years would 
be good enough for me, Haiku is still in alpha so it's probably a 
good idea to wait a bit more. From what I heard they now have a few 
people working on it full time (paid) thanks to a lot of donations, 
so there is a lot of stuff going on with the Haiku code base right 
now :)

I don't remember exactly, but COMPARE should be a little bit faster 
and has the advantage of being to able to return NONE if desired

Very nice Geomol!  Impressive speed - quite a bit faster than mine 
(i need to see what i messed up ;) )

a file should be able to have several paths (a bit like symbolic 
links in unix)  each one with different properties based on app context.

that's the point of having a full VM installed in the transition 
period.  yess it takes disk space, but at least you only keep the 
legacy things within the legacy environment.  they could have gone 
100% 64bit for example and not have to support 32 bit modes within 
the 64 bit and also distribute a 32 and 64 bit version, things like 
that where there are already many *current* apps which fail in one 
or the other.  my friend can't get her camera to work on windows 
7 cause its only compiled as a 32 bit app (drivers and all).  but 
she was forced to use a 64 bit win7 because of support issues.

brian, true.  my error... I'm deep in calculus... my brain is a bit 
mushy ;-)


IIRC the RFC has an BNF-style breakdown, so there should be no surprise 
as to where hexing can and should be interpreted.

It has been put on hold for a bit in favor of R3 development, but 
not canceled.

Have the registry bugs been reported? If not, do so here or in RAMBO. 
(I am a bit new to the RAMBO admin process.)

Not yet, as R3 is a bit of a moving target. Most R2 code will run 
in R3 if it doesn't use any GUI or port code. Part of the migration 
strategy has been the R2/Forward stuff, which allows you to write 
code in a more R3-like way in R2. Plus, we are backporting some of 
the native enhancements that are additive rather than changing, like 
SELECT on objects.

am I the only one who notices that cut and paste is completely broken 
on Rebol2 new releases?
 - most probably yes, it works for me - Windows 7 64-bit

-- arrays of 128 bit cells

R3 also does not have a 64 bit path mapped for it

We're a bit OT here, don't want to hijack the group.

It may well be that REBOL uses a 128-bit block size with Rijndael 
but it isn't clear from the documentation.

I am making a simple (I hope) worfkflow prototype and want to use 
REBOL objects which I can SAVE and LOAD.  A workflow object!  to 
have a node-map collection in it of simple nodes of the workflow 
graph.   Source ->A -> B -> SINK where the workflow knows about the 
next node and status. Externally there is UI to support the work 
part ... which is URL data on a given node.   Looks like it fits 
into Cheyenne RSP well - maybe zmq when I get a bit further along. 
  Save a flow in process as a .txt file using SAVE/ALL filename.txt 
work-flow-instance.   But no success with work-flow-instance: LOAD 
filename.txt        Do I have to BIND on LOAD to re-instantiate the 
object?

For a scanner (also called lexical analyser), I can recommend studying 
the UNIX command lex. The code produced might be a bit bigger in 
size, but it's fast and produce good result.

If you know the context you want to use and it is always the same, 
then it is a bit inefficient to call the BIND function, not to mention, 
that

    bind 'v 'f

is more efficient than
 
    bind 'v bound? 'f

NEW-LINE is magically delicious to me. I do quite a bit of code and 
data generation, so I use it a lot.

unless someone finds a better alternative, I don't see anything wrong 
with this syntax... maybe it needs a bit more components (like keeping 
tabs on the index of the block).  
in fact  maybe this is even better:

 #[block  #1 2 [ val1 val2 ]] 


here an issue type is used for the uid and the integer is used as 
the block index.

I came across a funny thing with binding. We've learnt, that the 
binding of words in a block is done, when the words are put into 
the block. This little example with two functions illustrate that:

blk: []

f: func [
	v
][
	insert blk 'v
	g v
]

g: func [
	v
][
	if v = 3 [exit]
	print ["v:" v]
	probe reduce blk
	g v + 1
]


F puts the word V into the block, then calls G, that has its own 
V. When G reduce the block, we see the original value of V from F, 
even if Gs V is changed:

>> f 1
v: 1
[1]
v: 2
[1]


Then I tried this next function, which puts V in the block in the 
start, then call itself with changed V value:

f: func [
	v
][
	if v = 3 [exit]
	if v = 1 [insert blk 'v]
	print ["v:" v]
	probe reduce blk
	f v + 1
]

>> clear blk
== []
>> f 1
v: 1
[1]
v: 2
[2]


This time, we see the latest version of V. The first V, which has 
the value 1, was put in the block, and it's still there somewhere 
in the system, but we get the V value from the latest F.

Is this a problem or a benefit, or is it just a bit strange?

Doing it that way shrinks the startup time and memory quite a bit. 
There's a lot of the loading process that is dedicated to reducing 
code copying.

(always copy would make sense only if rebol could do copy on write 
- which is a bit tricky. given the way rebol works "never copy" makes 
much more sense, then you add copy to helpers like FUNC etc. Then, 
we can discuss whether CONTEXT should have a copy, and imho it should 
not because this "bug" never happens in practice.)

Ok, now we're getting somewhere. A question is raised, if MAKE should 
copy arguments given to it. This isn't the bug, as I see it, and 
I'll explain that a bit later.


But first, if MAKE disn't copy the body block when making a function, 
then we would be able to change the function by changing the original 
block. Like:

>> b: []   
== []
>> f: make function! [] b
>> f
>> insert b 42
== []
>> f


After the last call to f, we would get the result 42, if the body 
block wasn't copied. This is not desirable to me. Is it to you guys?

...Because the locals live on, this was a problem for me years ago. 
First I solved it by putting COPY in series definitions...

 - sorry to chime in, but I simply have to. The issues you mention 
 (series in functions, extent of function locals) are not related. 
 For example, the extent of function locals has changed a bit in R3, 
 while the issue with series remains unchanged.

and it's more useful than the other way I think. Once I wrote a function 
to test if two object is similar. It looks a bit silly but works 
for me. Can be extended to test values also:

similar?: func [
    {Returns true if both object has same words in same types.}
    o [object!] p [object!] /local test
][

    test: [if not equal? type? get in o word type? get in p word [return 
    false]]
    foreach word sort first o test
    foreach word sort first p test
    true
]

BTW, I am a bit annoyed by needing to bind a user-supplied block, 
and having to always recreate a function because of that. I would 
prefer to just BIND, as in R2, which is technically possible, just 
unsupported.

I've been thinking about this before, and there was a discussion 
on Carl's blog long time ago. It came to me again, when I looked 
at LOWERCASE and UPPERCASE. They work on strings, and does change 
the sting. But many functions work on string without changing them. 
That's a bit odd, or maybe difficult for new users to understand.

that seems a bit impractical, but I guess it could complicate the 
function to have both ways.

R2's COLLECT is pretty similar. The backports try to be as compatible 
with R3 as is practical in R2, though is a couple cases they are 
a bit ahead of their R3 versions, where there are some tickets that 
haven't gone through yet. In particular ENLINE/with, DELINE block!, 
and MAP-EACH/into come to mind.

Example of what I find a bit strange:

>> load ""
== []
>> load "1"
== 1
>> load "1 2"
== [1 2]

I do something similar, generating 10'000 lines and writing to a 
file takes 5-6 seconds to complete on my Intel Core 2 Duo E7400 (2.8 
Ghz) 3GB RAM.

500'000 lines a bit too much but you read the whole file into memory 
so it is possible. Your PC is a good one as well I think.

I need to extract the data from an image file so it does not include 
the "64#" header and I just have the 64 bit encoding: 

64#{
/9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa
AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
is3eIoxUdG7n/9k=
}


I just wnat the stuff between the quotes but as its a binary I can't 
seem to parse it or extract it with other methods like a text file.

at first glance a bit confusing, but actually it's ok. >> shift 257 
65 == 128

Think what will happen, if the application move from 32-bit to 64-bit.

And the mod by 32 for a rotate is only ok on a 32-bit system, on 
a 64-bit it's mod by 64. And only for integers, not binaries etc.

That's right, but only if your "interpreter" supports 64 bit integers.

My example is doing bit shifting right (decreasing value) by 2 bits 
at a time. The bits falling off each byte isn't carried over to the 
next byte.

(Or a renamed /case option. A bit hypothetical due to backwards compatibility, 
but mentioning it for the sake of completeness.)

We don't use denormalized numbers or anything like that which would 
make numbers with different bit patterns refer to the same number?

Interesting. How does that happen? I thought SAME? just did a bit-for-bit 
comparison.

yes, but the NEW-LINE? bit is ignored

I didn't even know there was a newline bit, though it seems obvious 
in retrospect. It would be lost in the transfer of the value to the 
stack frame for the function call I bet, because stack frames and 
value slots of contexts don't keep track of newlines. You'd have 
to pass in a reference to the block the value is stored in, I'm guessing.

I used to think that newlines in blocks were hidden values in the 
block itself. It makes sense to just have it be a bit in a value 
slot.

It is a value bit.

Well, the latter is probably why same? does not respect this bit, 
no :) ?

Immediate values are a bit iffy concept in REBOL anyways, so it's 
probably for the best that you don't use the notion. Nonetheless, 
there is a documentary typeset in R3 called immediate!, which includes 
the values that are fully stored within a value slot, rather than 
referencing memory elsewhere.

128 bit for a value slot is hurts a lot in some cases

I just realized that if Carl is using a hash table for some of the 
set functions... does this mean that its subject to the 24 bit hash 
problem we discovered in maps?

though I guess it requires a bit more structured code than rebol 
to properly predict what is expected to be volatile.

Max: the current supported types in Red/System are all of same size. 
Makes a lot of things easier, but I will need 8 and 16-bit sizes 
very soon, so the simplicity of implementation will probably suffer 
a little from that.

The original Java case benefits more from the concept than REBOL 
would because there are many addon standards like JavaDoc that need 
managing, but at least have been agreed upon by their community. 
We don't have that kind of agreement in the REBOL community. Also, 
the structure of the Java language is very limited, so it's a bit 
easier to parse it and have its structure just be in the background 
even though the language wasn't designed for that like Smalltalk 
was for its browser. For Red, since it's so early, things like integrated 
documentation can be developed along with the language, so something 
like this would make more sense. However, if Red is going to have 
even a large fraction of the power of REBOL then it won't be as structured 
as Java, making it a little more difficult to retrofit a Code Bubbles 
interface onto existing code. This is why you would need an IDE to 
understand code written in this kind of IDE: A Code Bubbles style 
interface doesn't generate code with story structure the way scripts 
are structured, so you can't just read the code without the context 
of the IDE.

Brian: yes, for financial usage, so might differ a bit from REBOL's 
money! type.

Once Red is a bit more mature, it will be quite a bit easier to write 
bindings for Red than for R3

ELF seems to be a bit smarter about page loading, it doesn't require 
explicit padding to page boundaries in the file itself, so can generate 
smaller exe. (It's possible with PE too with some hacking).

The preprocessor is a bit too aggressive.

Although I'm running into a bit of a wall when I try to import functions 
under cdecl. I'm getting undefined symbols (path values into the 
emitter symbol table) all over the place

Each routine has several implementations depending on the features 
available at runtime in the CPU (SSE, SSE2, SSE3,...). So, it's a 
bit too large for my needs (I would prefer selecting the best implementation 
at compile-time).

It requires 32-bit integer support for source compatibility with 
other platforms, but if you don't care about compatibility, it should 
be possible to make a 6502 emitter ;-)

6502 is a bit far reach with its 8/16 bits architecture, but 68k 
should be doable while preserving all Red/System's features.

I need to re-factor the code a bit as we have a commercial extension 
that is currently included in the main source-code. So I need to 
seperate these, to release the public part.