AltME groups: search

Yes - both the native 'checksum and the published 'crc-32 works on 
a string! or a binary!, not a port! . For crc-32, the crc must be 
initialized at start, and complement'ed (bitwise 'not) at end.

crc-32.r with gigabytes files: [don't do it] - it works, the memory 
used isn't size relative - but on a 1GHz PIII, the speed is < 300 
kbytes/s! 
rebcode version is a lot faster (>2Mbytes/s), but 
1) rebcode isn't part of official releases 
2) the rebcode version of 'crc-32 needs whole file in memory.

so, back to RAMBO: #3650 - I vote for 'crc32 as another 'checksum/method, 

and maybe a RAMBO ticket for a port aware version of 'checksum would 
be a good idea.

I think this is a bug:
>> read http://www.paseka.cz/obalky%5C80-7185-652-5.jpg

** User Error: URL error: http://www.paseka.cz/obalky\80-7185-652-5.jpg
** Near: read http://www.paseka.cz/obalky\80-7185-652-5.jpg

I am having a serious problem:

    parse [*] ['*] ; == true

but

>> parse [/] ['/]
** Syntax Error: Invalid word-lit -- '
** Near: (line 1) parse [/] ['/]


The same problem exists for '// . Is there a way how to circumvent 
it?

hmm, the situation with comma *can* be handled this way too, but 
comma normally isn't a REBOL word

I guess there is a problem with rebol loader, because it needs quoting 
of some "special" chars.

The rebol parser should understand '/ and not required to-litword! 
"/", specially when the latter is a valid expression.

Gab or some RAMBO editor, can you update RAMBO ticket #4087

there is a workaround from Edgar which is to so system/ports/serial: 
[ttyS0 ttyS1] to patch the ubuntu port of REBOL.  I suspect that 
can be done in a future release for ubuntu, but at least for now 
I have a workaround.

I've got an interesting bug:  If you enable the outer detect, the 
inner detect receives a face object to its EVENT argument. Weird.

Is this a known issue? LINEAR in the draw dialect's FILL-PEN command 
seems to be case-sensitive, it throws an error if given in uppercase:

Anton: it looks like a bug to me.

Use and word:

>> same? 'a first use 'a [['a]]
== true

Use and get-word:

>> same? 'a first use [:a] [['a]]
== true

Use and lit-word:

>> same? 'a first use ['a] [[a]]
== true

Use and word:

>> same? 'a use 'a ['a]
== true

Use and get-word:

>> same? 'a use [:a] ['a]
== true

Use and lit-word:

>> same? 'a first use ['a] ['a]
== true

sorry: Use and lit-word:

>> same? 'a use ['a] ['a]
== true

word1: 'a
word2: first use 'a [[a]]
if all [not value? word1  same? word1 word2]["sameness unknown"]

Oh, I see you are concentrating on USE.
>> use 'a [a: 123]
== 123
>> a   ; <--- word in global context
== 123  ; <-- supposed to be still unset

Looks like a bug to me.

Ladislav, yes add it please. i remember seeing a report about this 
but maybe it never got into rambo.

I just posted a RAMBO entry (currently #-663), accidently before 
I was finished writing it. There are errors. What do I do?

;Little bug in formatting, worth a ticket?
probe [
 0
]
probe [
 12
]
==
[0
]
[
    12
]

got this error from a rebol process launched by another rebol process 
running uniserve:

dyld: Library not loaded: /usr/lib/libncurses.5.4.dylib
Referenced 
from: /bin/bash
Reason: image not found
*** Boot Error 951
What may that Boot Error 951 be?

dear all, does anyone have an idea about  "Boot Error 951" mentioned 
above? Is it a rebol initialization problem? Maybe betwen rebol process 
and its dns resolving brother process?
..or is it more related to uniserve code? thx

thank you Anton, but /usr/lib/libncurses.5.4.dylib does exist! After 
a while rebol process launched by main uniserve process show this 
error and then rebol seams to loose ability to read/write files, 
restarting brings everything back to normal,

*** Boot Error 951

 is this a rebol error that should not happen or is it a programming 
 error?

This is a rebol error message - "*** Boot Error %d" appears in a 
recent rebview.exe - but I think the error code 951 is being passed 
to rebol from an OS call.

I think this question should be asked and discussed in the Uniserve 
group until Uniserve is eliminated as a possible cause.

re #4116 - the same bug happens even via ODBC Oracle driver. So maybe 
Oracle driver is just a wrapper to ODBC? My suspicion is, that result 
of such query is non-standard, it is returned to the pipe, and rebol 
crashes by trying to parse it. Just a wild speculation though ...

That's obviously used in Rebol/Link. A quick helper function. Maybe 
it's not supposed to be exposed.

The request-download bug above I think is caused because file is 
actually a directory. So, the port type is 'directory and so the 
insert fails.

request-download usually works fine, you just need to provide a file. 
it downloads to the cache by default.

A better error message can be thrown in read-thru by detecting the 
url without a file component.

The request-download bug is a bug in read-thru. Fix the bug in read-thru 
and you fix the bug in request-download.

I think the wisest thing to do when given a url without a file component 
is throw an appropriate error. I don't advise downloading anything 
because we don't know how the webserver is mapping the url to its 
filesystem (if it is in fact doing that.)

it seems to happen if you are specifying the pen attributes and you 
accidentally include something else, like a drawing command, but 
the drawing command has to be somewhat complete to trigger the bug. 
interestingly, setting the box size to 0x0 does not trigger the bug, 
maybe because the draw block is not performed when the box is 0x0.

; mold/all/flat broken on my ubuntu. Other systems too?
o: context [a: 1] 
probe mold/all o 
probe mold/flat o 
print "pre-crash" 
probe mold/all/flat o 
print "survived"

; WindowsXP
>> mold/all/flat o
== "#[object! [^/a: 1^/]]"

well, I sort of agree on that. While I haven't found any problems 
getting a decimal! returned, the datatype for the result is changed. 
There will always be overhead, if you are changing the datatype. 
I suppose it would be rather confusing to have:

>> divide 1 2
== 0

and having to remember to present one of the values as decimal

>> divide 1 2.0
== 0.5

maybe an 'intdivide could be provided?

I don't agree with #4085. REBOL gives human friendly responses. There 
are times where I wouldn't mind having an integer division *alternative*, 
but I've gotten along without it so far, and the performance concern 
is hardly a high priority IMO.

Ladislav, while it nice to see APPLY being put on the front burner 
(RAMBO 3575), I have a problem with Carl's proposal. His examples 
clearly do not evaluate their function argument (like HELP or SOURCE), 
but this would prevent using APPLY with anonymous functions. It would 
be preferable to require the function to be specified with a get-word 
like this:
    f: func [a b] [a + b]
    a: [1 2]
    apply :f a

oh... sorry, I didn't realise you where saying that the issue is 
there since a long time.

I guess its a dialect loophole.

#4085 - I think the submitter "-X-" is a certain individual who was 
active around that time (22-Apr-2006) and who was banned from our 
world.

(i really can't see how divide returning decimal would be a show 
stopper though.)

b: reduce [path [()] 1] - isn't this a bug which should be put to 
RAMBO?

(I meant, it's unfair to say, that it does not return a value. About 
returning a value that's worth having ... well, that's another can 
of worms altogether ;-)

it would be nice to have a working PATH action though (not the current 
one which seems to be an internal thing)

speaking about VID memory leak. "but its some intermittent thing... 
like I said previously, I never got around to tracking it... I only 
know something within VID, especially when creating many stylesheets 
dynamically, eventually grows mem use a lot."

glayout, being a nested VID engine, will effectively call layout 
many times each one might have its own style word calls.

Alright, these are serious issues, so I would like to set up a demo 
of this and try to isolate.

its not always obvious, but in larger apps (the likes of altme) there 
is a memory increase all the while you play around...

I remember that I was able to get the same issues using only VID, 
so GLayout was not the source cause... it was only amplifying a VID/View 
bug.

yess. I will try to write up a very small and unsexy test... give 
me 5

the GC in 1.3.2 was improved a lot.

I think I'll try to make a forever loop and log stats to a file, 
then maybe graph the stats to see what happens towards the end.

I was able to allocate 1 million liquid nodes (~ 700MB worth of ram) 
and although the GC slows down a lot after 400MB, it does not crash, 
until  you start missing real RAM.

not anymore... I'm not setup for this anymore... unfortunately, I 
don't have a lot of time tonight... I have to test cheyenne and start 
putting my web site back online in order to get slim, glayout and 
liquid  "out in the open".

(and am still fiddling around with a cleaner http-post func)

but IIRC I can still see the mem leak in GLayout... so maybe another 
time I can look in my old dev backups and find a VID test I had done 
which re-created the leak.

One has to be careful reloading scripts in the same console multiple 
times as this will also eat up hundreds of MB's of memory. I'm sure 
that I'm doing something "wrong" in those scripts, but have no time 
to investigate what it is. I wanted to ask earlier on a memory usage 
group and that we don't have one. Wouldn't it be nice to get laid 
out what techniques are useful in order to converve memory? Maybe 
the experts can put in a word or two on that. View does indeed also 
eat lots of memory, as well as image creation with to-image.

Henrik, yes, I know this problem. Looks to me that some things aren't 
reseted. You can see this, if you have a face A in the first run 
and than a face B (and not A anymore) in the second run. A is still 
available.

try/recover - that is how Carl wanted it to be. (he didn't want to 
define a new function)

(because only a native can discern a "live" error and a "computed" 
one)

The advantage of "reusing" TRY is, that the code will be easier to 
maintain this way (TRY and DEFAULT would have a lot of common code 
otherwise)

#4124 "set-modes doesn't work on file directories" - maybe add a 
note to Paul here that "the filesystem may not support setting all 
of the modes that are gettable by get-modes. For instance you can't 
set modification-date, but you can set the owner-write flag." Maybe 
there should be a more informative access error type, not just "Cannot 
open ...".

will you be online for a few minutes?

Anton, error #4124 is not a filesystem problem. I replicated it here, 
on NTFS, in a directory that I have permission to do anything. NTFS 
supports changing the modification date of directories - I have an 
Explorer shell extension that does just that, as well as a command 
line touch utility. REBOL can change that attribute on files, but 
not directories. REBOL is probably hust using the wrong API.

I accidentally put a string in the font size, like this:

view layout [area font [size: "m"]]


Windows gives me a small font, which seems right. On OSX I either 
get screen trashing inside the text area, hanging or a segmentation 
fault.

Is there any simple way to add a screenshot upload function to the 
RAMBO script? Or has anyone done it already?

No objections on anything that causes a segfault (unless, of course, 
it's already in rambo somewhere.)

I like the idea from the R3 blogs about having SYSTEM be a function 
that generates objects, rather than an object. That way system/script 
would return an object that wouldn't mess up the infrastructure when 
it is changed.

many points in many r3 discussion would be moot with this simple 
concept added to a new class! or current object! engine.

I have been a big advocate of accessors here and in the blog comments, 
though mostly for interoperability with other object models that 
have them (all of the major platforms now). Safety is a good reason 
for them as well.

and invisible datatype... with accessors, I could code a liquid api 
which is completely hidden from users... totally non-aggressive to 
the way they currently code and yet still allow custom types of liquid, 
just by changing how the accessors are built.

So, no objections to me creating a ticket for that ?

I think I understand - it is simply that some "variable" is not variable, 
but a function? In Visual Objects, we could define variable being 
an accessor, you then normally used oMyObject:myVar: 3 - which could 
mean - you either assign it to variable, or (if an accessor), the 
same syntax is being used, but it was passed as a parameter to function, 
which could do type checking, whatever ...

Yup, something like that. Accessors were introduced in Self, then 
ported to Delphi (as properties), then from there to ActiveX, Java 
(as a coding convention), C# (and the rest of .NET), and then many 
other modern languages and platforms (most of the major ones).

Python is designed that way now, but it didn't start that way. That's 
something I like about Python - when they add new features in a new 
version, they are not afraid to redesign the whole system to take 
advantage of the new features.

what do you think about these:

>> p: make port! http://
>> equal? reduce [p] reduce [p]
== true
>> equal? p p
** Access Error: Port none not open
** Near: equal? p p

or

>> a: tail [1]
== []
>> remove head a
== []
>> equal? reduce [a] reduce [a]
== true
>> equal? a a
** Script Error: Out of range or past end
** Near: equal? a a

It does look like a problem. Things like this are funny, because 
it seems like an obvious issue we would have hit long ago. :-\

No. Let me try a fresh console.

That one comes back to the old issue of out of range indexes, which 
has been around for a long time, correct?

but my point is, that you cannot state comparing A with A may be 
an error without asking for trouble

I would say that you can't do *anything* safely on a series reference.

I guess it would be useful to have a FIND/LITERAL refinement to behave 
differently when searching for datatypes

this is my gripe with lists:

>> a: make list! [1 2 3] clear a tail? a
** Script Error: Out of range or past end
** Near: tail? a

Yes, I agree. I suppose EQUAL? is COPYing the port, what do you think 
? Maybe it's just a minor implementation flaw. Can you see what it 
might be ?

I think it may only be a side-effect of an incomplete implementation.

I do admit that he has a point wrt how the help states things. if 
 there is a stated difference between  '=  and '==   then maybe the 
'= should be expanded (and explicitely documented)  for obviously 
equal values...

like char and one letter string,
$ and equivalent decimal,
 etc.

char and one-letter string is not "obvious" for me, but a more "obvious" 
thing may be a comparison of [a] versus (a) or "a" versus %a etc.

isn't a character and "one letter" the same thing semantically?

I know many people would like to expand these to include empty strings 
and 0, just like python does... but in such a case, many usefull 
uses of any/all will loose their value.

You have to draw the line somewhere. I think we'd have to discuss 
it on a case-by-case basis, because you can't always substitute one 
value for another, e.g. strings, files, and urls. So, even though 
it seems like two any-string! values could be compared safely, that 
might not work in our favor in real life. We could create a matrix 
and examples for duscussion; I'd be hesitant to change it without 
deeper thought.

yes obviously, and we could also add a new "loose" equality ~= or 
whatever... but in any case... all matching type-pairs should be 
explicitely explained and documented.

in some types this will have a lot of meaning/differentiation  ... 
take the date for example... do we equate the number of seconds, 
or the lexical textual form... or both, depending on other type pair...

I think this would be a very nice session/panel for devcon 2007 with 
Carl and Gurus as panel members and any one able to assist and give 
insight.

In practice, a programmer would notice the failed equality, then 
convert to a datatype which supports the equality operation.