AltME groups: search

Good news!
So you have a few days to fix the recycle problem for real :-)

actually I'm going to look at a printerserver, which deadlocks, if 
two people are trying to print too close to eachother.

it's not a problem the other way around, so yes, it's inconsistent.

anyone willing to find a way to reproduce it?

I don't have anything trivial that will trigger the bug. It's a big 
application that can run for a while before crashing....And the code 
has been tweaked to minimise the occurrence of the problem.

but at this point (focused on R3) RT does not have enough resources 
to debug a big app.

well, if it's about memory allocation and clean up, would there not 
be a way to torture it? What's the worst possible way to stress the 
garbage collector?

something that randomly creates a large amount of blocks, inserts, 
deletes, manipulates, copies and does various other things.

there is a silly bug in my patch, it should be:
use [tmp][

 tmp: select second get in system/schemes/http/handler 'open to-set-word 
 'response-actions
	if none? find tmp 303 [ insert tmp reduce [303 select tmp 302] ]
]

Oldes, how do you classify this patch ? Is it simply improving Rebol's 
HTTP 1.0 scheme, or is it half-way sliding towards HTTP 1.1 ?
(ie. does the official HTTP 1.0 spec contain a 303 response ?)

(if not, then this should be called a "workaround patch" or "temporary 
migration patch")

Ok, so let me restate the situation:

Due to a buggy foreign server, we are patching our HTTP scheme, which 
declares itself as HTTP1.0, with a part from HTTP1.1.
(I just want to clarify that HTTP 1.0 does not contain 303.)

Note: Many pre-HTTP/1.1 user agents do not understand the 303

      status. When interoperability with such clients is a concern, the

      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

Copy/part can't use a path! as its RANGE argument

>> path: 'svvc/color
== svvc/color

>> copy/part path back tail path
** Script Error: Invalid /part count: color
** Near: copy/part path back tail path

This is interesting because a path is a series, supposedly very similar 
to a block.

I'm studying memory usage and recycle for a bit. Whenever I'm adding 
a block or doing an operation, REBOL might consume small chunks of 
memory continuously, like 16-32 kb per second. whenever recycle is 
applied, it just stops. Why is that?

I must point out that recycle specifically was turned off and so 
the number would just keep growing for hours eating up 100s of MB. 
Recycle is probably normally invoked, if you don't specify that it 
has to be turned off. The fact that the memory usage just keeps growing 
in an idle situation seems just like a memory leak to me.

a: [ append a [+ 1] 1]

loop 1000 [ print [ do a newline ] print [ "Block length: " length? 
a "Bytes used: " ((length? a) * 16) ] ]

henrik, with recycle/off, no memory is ever reused, and obviously 
rebol is constantly allocating memory for temporary values and so 
on. so used memory grows. when you do a recycle, the gc will collect 
all the garbage and start reusing it for later allocations, so that 
memory used stops to grow until you get to the same point as before 
and rebol needs more memory.

I just think there should be better clarity on what are do's and 
don'ts in terms of how to preserve memory and have a stable application 
at the same time. Some apps of mine never eat more than 3-5 MB RAM, 
while others eat 250 MB RAM, and I don't know what causes it.

Gabriele, could you please add this note to #3867:

Update: I now understand that the events trickle down in a dynamic 
fashion and it cannot be known (for certain) at the beginning whether 
an event will arrive at a particular face, as DETECT functions along 
the way to the face can alter the route. -Anton

i think there was a reason for it being critical... hmm.

Why can't we get a directory requestor?

i don't think there's a fixed list that has been written yet.

Shall I create a R3 list here then ?  :(

IIRC, there should be VID+ group, which was supposed to discuss what 
direction new VID should go. There is many talented ppl with various 
povs here, who could influence some decision in a good way imo ...

All right.  Two Brians...We win.

But Pekr;  RT has to be careful with this.  Giving it out to too 
many will just generate

too much noise...  I'd gladly take my name off the list and wait, 
as to not overwhelm

those in more appropriate positions...I'd rather get handed Government 
Reject Unfit

for Normal Training work.  Not that it isn't a nice shiny carrot 
dangling ever so close

to the nose.  And, being a little schizoid, I also agree with you.

I surely hope you allow us to nominate you for Secretary of the (proposed) 

REBOL User Group. The (proposed) Executive Summary could definitely 
use your
candor.  :)

petr, remember the open view 1.3 project? the problem it didn't get 
anywhere (despite producing a lot of good code) is that Carl does 
not work that way. we can only aknowledge it.

Gabriele,
Can you please take a look at these 2 submissions:

http://www.rebol.net/cgi-bin/rambo.r?id=4274&
http://www.rebol.net/cgi-bin/rambo.r?id=4161&


I am desperate because center and left aligned text can not be edited.

Ca you please help?

I convinced myself and 2 others to go REBOL with a small but important 
app I need, but simple stuff like this kills the idea.

You meant, center and *right* aligned text can not be edited.

But yes, this is a long-standing bug, and it's annoyed me a few times.
Actually, this is something that *could* be worked around.

We just need to figure out how caret-to-offset and offset-to-caret 
work, then write mezzanines to replace them. I've been meaning to 
do this for a while.

Dear Anton,

A mezzanine, that's it. 
I can not tell you how frustrated I am.

See my response to Gabriele below:
Thanks for the info.


It is so sad to see that "little" things are not fixed in a reasonable 
fashion.

Here I am, 99% of my stuff is Center aligned and I find myself "regretting" 
that I go for a "not so established" language.
(never thought that entering text in a box will be a problem)


I have to actually ask 1000 people to klick 4 times more often, just 
to overcome a stupid bug.
So I ask them to:

Change to left align
Edit
Go back to Center align

Repeat as long as needed and pardon, I used "REBOL"

Best regards


So, what is needed to fix this, please let's include Ashley

Thanks a ton for the shimmer of light I see at the end of the tunnel
Peter

Volker, 
Thanks that saves a few, indeed.

My frustation is that we have to be to "REBOLish", a text box is 
as simple as it gets (maybe excluding a label), one can not be forced 
to adapt to the bugs and "adapt" to a new enforced way of editing 
text !!!

The issue I wanted to point out is just that if it's an existing 
file!, I should be able to read it ! So instead of letting the user 
wrongly think that's a file, and let 'read pop an error (which sounds 
illogical to me), I'm proposition to signal in 'info? that something 
is wrong with that file! value.

specs: info? a-file
if specs/type = 'file [
	probe read a-file
]

** Access Error: Cannot open /C/Dev/REBOL/script.r/
** Near: read a-file

It is with pleasure that I can announce that there is a workaround 
to the center / right aligned text highlighting issue. I have a working 
prototype. You can change the horizontal alignment of the face on 
the fly. Give me a day or two to clean it up and make a nice demo.

There is a bug in decode-url:
>> probe decode-url http://test/path/target?text/something
make object! [
    user: none
    pass: none
    host: "test"
    port-id: none
    path: "path/target?text/"
    target: "something"
]

the target should be: target?text/something

Is it so difficult to remove a char from charset or I forgot something?

why this is not working?

>> remove charset "abc" "a"
** Script Error: Invalid argument: none
** Near: remove charset "abc" "a"

when in doc is:

Character sets can also be modified with the insert and remove functions, 
or combinations of sets can be created with the union and intersect 
functions.

Charsets don't always respond the way you'd expect -- or support 
all the operators they could.
One way to remove a char: use difference:
    >> (charset "ac") = (difference charset "abc" charset "b")
    == true

Try this:
remove/part charset "abc" "a"

The /part is necessary when removing from a bitset,

Also note, to get the caret and highlight handling / rendering working 
properly will require you to do in Rebgui the equivalent of the above 
ctx-text patching etc. That's quite a bit of work.

never mind, you can delete it, I already have a solution... anyway... 
it would be nice to replace the clean-path function with the Anton's 
simple-clean-path

How about this on your end...just trying to reduce the code for the 
RAMBO report.


foreach a to block! {'word} [print get a]  - this segfaults on Linux. 
too.

to block! does not bind. word is not included in system/words. sometimes 
that results in an error-mesage and sometimes in a crash.

Is rhis a bug, or just undocumented behavior?
   trim "  a  ^/  ^/  a  "
   == "a^/^/a"

The help says "Removes whitespace from a string. Default removes 
from head and tail." But in this case it seems to treat the string 
as a set of strings (separated  by  newline) and trims them all.
Compare with the expected behavior here:
   trim "  a  b  a  "
   == "a  b  a"

TRIM behaviour is strange.  Sometimes it removes too much as in your 
case, sometimes it removes too little as in (trim "^/a^/" == "a^/") 
. I would say it's a bug.

I'm beginning to think so too, especially as (from my reading of 
the function), these two should be equivalent
trim/head/trail "  a  ^/  ^/  a  "
trim"  a  ^/  ^/  a  "

Hence why I always use trim/head/tail...  I didn't think it was a 
bug, though, since your first example - trim "  a  ^/  ^/  a  " - 
could be a shortcut for data files..  Trimming each line.

On windows platforms, you'll get the infamous DOS window flashing 
when executing an external CGI ! It's just a matter of 1 flag to 
correctly set in 'call C source code, if you're really annoyed by 
that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I 
may reimplement completely call command in REBOL, but it would be 
a big waste of time and energy...it should be a 10 minutes fix for 
RT. Addind a time limit to 'call would be a good thing too, it would 
also avoid me the reimplementation of 'call to add such feature....
 - DocKimbel

Anx chance of getting above fixed? Should we rambo it?

RAMBO lacks a free commenting support...

Re my trim question of a week or so ago....
Thanks for the responses.
From RAMBO it seems this is deliberate (if unexpected) behavior:
http://www.rebol.net/cgi-bin/rambo.r?id=3681

This is intentional and not a bug. TRIM was designed that way to 
work well for trimming LINES of text. 
 [my emphasis of lineS, plural]

DocKimbel, #4288 looks to me like it inserts a molded object into 
the path.

Yes, it returns the object source and the point is is this useful 
to anyone ? I was hoping the behaviour of :b in a path! could be 
changed to something more useful, like acting as a pass-thru to /c, 
so that, in the ticket example, a/:b/c would results in %path/target.

slipping objects into a path...

>> a: %path
== %path
>> b: context [c: %target]
>> a/:b/c
== %path/c: %target%0A/c
>> a/(:b/c)
== %path/target

btw, a/(:b/c) is quite heavy => 3 series instead of 1.

yes, but semantically a/:b/c is a/(b)/c not a/(b/c) which is what 
you want.

Do we still bother reporting to RAMBO?  Is there any expecations 
for a production 2.7.6?  I'd vote; please please please.

[ 4321 ] this is actualy  a borderliner.. Im not sure this is default 
behavior in windows or not, liinux does not have this problem, could 
stay open..

I've just run in a bug in enface.exe (2.7.6.3.1). The following code 
doesn't give the same result if run under view  or encapped with 
enface :

I think this might be in RAMBO already. At least I remember mentioning 
this problem to Carl a few years back. As Brian says, it's a missing 
/ALL refinement.

can you add a rebol captcha to it  to save you work?

I've searched RAMBO about a WAIT inconsistency : the dictionnary 
says that "If the value is a DATE/TIME, wait until that DATE/TIME", 
but date! are not accepted as argument (both directly or in a block). 
If this a known bug? I can't find it in RAMBO.

doesn't it mean a time value?

It's probably a documentation issue.

Precisely, I'm working on a scheduler lib for UniServe and I was 
wondering if I could wait for date!, but it looks like not.

good idea. create a curecode wish for it, please.

An excellent solution, but you still can't wait on a date!. :-)

what happens if someone changes the clock while you're waiting on 
a date! ?

What happens if someone changes the machine's clock while you wating 
for a length of time ?

graham, the only solution to that would be to wait, say, 10 seconds 
at a time, and check. but it really depends on the application...

Thanks Gabriele;  I knew there was a more concise method of getting 
at time!  from date arithmetic, but I got sidetracked when the google 
search wanted to show me COBOL data arithmetic.   ;)  Can't ever 
know enough COBOL, err, aaah, REBOL.

User-defined ops are a planned feature, not a currently working feature.

It's not a bad idea though. Still, CureCode that code you posted 
above. It's a serious bug that MAKE doesn't trigger an error there.

sounds like something for a private project?

I'd guess that if it's a product written in REBOL, the author is 
likely to hang out here... :-)


I'm going to leave it there for a couple days in case anyone needs 
it, then i'll delete or dismiss it.

It's not a RT product .. so I'd delete it

do you know it's not a RT product?

as cmd is a non gui product

that does not seem a lot of evidence to me... :)

Found a couple RAMBO tickets dated back to 13-May-2006 related to 
the double evaluation of lit-words:
http://www.rebol.net/cgi-bin/rambo.r?id=4100&
http://www.rebol.net/cgi-bin/rambo.r?id=4101&


The tickets suggest, USE might be the problem, but isn't it SAME? 
that's the problem here? See the following R2 code:

>> a: first ['word]
== 'word
>> b: 'word
== word
>> strict-equal? a b
== true
>> strict-equal? :a :b
== false
>> same? a b
== true
>> same? :a :b
== true


I would expect all 4 to return false, but with double evaluation 
of lit-words, the last should still be false.

:-D Actually, REBOL sounds a bit like a cartoon superhero.

I'm not clear on the issue. 1.3.61 was just a test release, wasn't 
it? And is there a UPC lib they're using that requires rebcode or 
something? i.e. what pages are being printed?

It seems to be a user of some random REBOL app. The version number 
may be the version of the app

Wasn't that a fire department?

I figured the author of the app would either be here, or be Carl 
(in which case I hope he'll eventually see the ticket, or he'll get 
a phone call from those guys).

A new ORCA one, combined with Syllable Desktop

Syllable GUI on Desktop, maybe a remote REBOL GUI on Server

A rebol gui thru ssh to the server?

do you have time for a day job?

Kaj, please make a XEN DomU out of it. I will give it immediatly 
a try. I'm searching for a base distro that can be used to create 
a complete application stack.

I think a Xen image would require the Syllable Server installation 
to support Xen in the kernel. Is that correct?

On the first conference we were invited to a 3D virtual worlds conference 
tomorrow in Amsterdam, with the ex CEO of Linden Labs and a university 
developing OpenCroquet speaking :-)

Yeah, but ten year old laptops take a week to compile a modern Linux 
distro

a conference on virtual worlds should have their conference in a 
virtual world

So it will still be a challenge to offer them REBOL solutions

Everyone I met on the conferences is building applications out of 
multiple diverse open source parts. I'm offering all of them to solve 
their integration issues by taking the boring parts out of their 
hands and integrating them in a custom Linux platform

A friend of mine was having difficulty installing Syllable the other 
day. He runs VirtualBox, because he has had more luck with that than 
VMware Server. I explained why there would be differences between 
the two, but it would still be nice for both to be supported. I realize 
that there is not as much point to supporting VirtualBox as it is 
more like VMware Workstation, not Server. Still, it has better memory 
allocation characteristics than VMware.

He has a recent enough processor that it has virtualization extensions, 
so VirtualBox isn't bad on it.