World: r3wp
[Core] Discuss core issues
older newer | first last |
PeterWood 29-Jan-2007 [6944] | This thread may help a little: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlHBNQ |
Graham 29-Jan-2007 [6945] | Thanks. |
Gabriele 29-Jan-2007 [6946] | henrik, unless rebol is using more than 2gb, i guess there must be something wrong :) |
Oldes 29-Jan-2007 [6947] | Henrik: it seems to be very bad. But it looks that OSX will not be such a bad OS if it allows you work even with apps eating so much memory. |
Henrik 29-Jan-2007 [6948x2] | it took some time to swap things back into memory. the script was working just fine though. |
I had a rugby script running all night that would periodically download 1 MB of data from another machine. I guess there was a leak. :-) | |
Oldes 29-Jan-2007 [6950] | I don't think it's fine if your script need so much memory:) |
Henrik 29-Jan-2007 [6951] | but it still ran instead of crashing. I think that's good, but isn't stats in need of a fix if it can't display mem usage above 2 GB? |
Oldes 29-Jan-2007 [6952x2] | that's because rebol don't have unsigned integers |
and probably nobody was expecting, someone will need so much memory | |
Ladislav 29-Jan-2007 [6954] | BACK versus past-tail indices. Every index (except for 1) may become past-tail during the execution of a script (when its block/string "shrinks") and "legal" again (when its block/string grows sufficiently). Let me mention the SAME? function as an example of a consistent behaviour - no matter whether the index is past-tail or not, the SAME? function takes it into account when comparing series. The BACK function, however, handles past-tail indices differently than the "normal" ones. any wishes/notes/proposals? |
Chris 29-Jan-2007 [6955x2] | Graham: re ports, there's not much art to it. You try and break up access to any particular service according to supported accessors. Almost all built in protocols are wrappers to a TCP port, containing all the commands for that particular protocol. Note that 'read on a port uses 4 accessors: init, open, copy, close; 'write also uses 4: init, open, insert, close; 'make will call 'init, whereas 'open will first 'init (unless you provide a port! as your argument -- eg. open make port! foo::bar), then 'open. You can use all the other accessors on an open port: insert, change, remove, etc. And of course 'query which you can assign to provide information about the port without opening it. I'd be happy for anyone to elaborate or correct this description... |
The sandbox port I wrote may serve as an example, except that it wraps a file port and not TCP. I hope to put together an article on this (before ports are changed completely in R3 :) | |
Pekr 29-Jan-2007 [6957x2] | Chris - you gained nice knowledge on ports! |
what about DevCon session? Will you attend? So far only Carl has registered his session .... | |
Chris 29-Jan-2007 [6959x3] | HTTP is broken up thusly -- INIT breaks down the url/spec, OPEN actually does all the heavy lifting, sending the request and parsing the response, COPY takes the final download from the buffer, and CLOSE closes the TCP port. |
Petr, I don't think at this point I'll be able to attend, much as I'd love to. Besides, ports are due for an overhaul in R3, so I'm not sure it's the best area for exploration right now. | |
That said, I find as an abstraction layer, they are super useful. I've been thinking about an adapter! datatype that replaces ports for data abstraction layers. | |
Pekr 29-Jan-2007 [6962x2] | I do remember some talks with DocKimbel when he actively developed R#. He told me that he would use two-fold aproach to port - separating low-level stuff, enabling more abstracted implementations above it .... |
let's see what comes with R3 .... | |
Graham 29-Jan-2007 [6964] | I just find the way protocols are done wrap the abstraction so tightly that you can't insert arbitrary command into a port without rewriting the protocol. Eg. adding the TOP command to POP. |
Maxim 29-Jan-2007 [6965x2] | the one thing I find strange comming from carl, is the fact that within Amiga, everything was a hook. so you could very easily re-implement everything... and most of the deep internals of REBOL are pretty boxed in... the stuff is still in box... but opening most of these secrets is like opening a can of worms... |
add to that the irritation cause by static binding.. which is cool for many things, but has this side effect of making many run-time code change much harder. | |
Anton 30-Jan-2007 [6967x2] | Eh? what's happening? Why are these different ? |
id: 0 foreach [a b c] [1 2 3 4 5 6] [print id: id + 1] use [vars id][ vars: [a b c] id: 0 foreach vars [1 2 3 4 5 6] [print id: id + 1] ] | |
Oldes 30-Jan-2007 [6969] | anton, because you set vars for each value:) |
Anton 30-Jan-2007 [6970] | omg. it stares me in the face. |
Oldes 30-Jan-2007 [6971x2] | you want to do: |
use [vars id][ vars: [a b c] id: 0 foreach :vars [1 2 3 4 5 6] [print id: id + 1] ] | |
Anton 30-Jan-2007 [6973x2] | ah nice, I was about to something with DO COMPOSE |
Thanks... :) In my actual code it was really confusing. | |
Oldes 30-Jan-2007 [6975] | maybe it would be good to give this into FAQ or something like that, if it exists:) |
Anton 30-Jan-2007 [6976] | Hmm... I'm not sure. I think the problem is that of coding too many hours without rest. |
Oldes 30-Jan-2007 [6977] | it's not so late:) |
Anton 30-Jan-2007 [6978] | Should put that in the FAQ: "How many hours should I code before taking a break ?" |
Oldes 30-Jan-2007 [6979] | It depends how strong you are:) |
Ladislav 30-Jan-2007 [6980] | insert/dup looks like not working when used on /binary/seek ports. Is that a known issue? |
Oldes 30-Jan-2007 [6981] | for me not |
Ladislav 30-Jan-2007 [6982x2] | what version? |
(I used rebol/version == 1.3.2.3.1) | |
Oldes 30-Jan-2007 [6984] | I mean, that didn't know that it's a problem:) |
Ladislav 30-Jan-2007 [6985] | aha, sorry for misunderstanding |
Gabriele 30-Jan-2007 [6986] | i don't think it's known, otoh /seek is known to have a few problems so it's not really surprising. :) |
Ladislav 30-Jan-2007 [6987x2] | thanks - RAMBO #4235 |
Anton - you ran into yet another case of nontransparent argument passing. Let me repeat - I don't like nontransparent argument passing... | |
Anton 30-Jan-2007 [6989x3] | It's just funny because FOREACH is used so often. |
I guess FOREACH would suffer much if the first argument was expected to be always a block! | |
would not suffer | |
Ladislav 31-Jan-2007 [6992x2] | try this: foreach': func [ "Evaluates a block for each value(s) in a series." word [word! block!] {Word or block of words to set each time (will be local)} data [series!] "The series to traverse" body [block!] "Block to evaluate each time" ] [ foreach :word :data :body ] |
(it is a referentially transparent argument passing variant) | |
older newer | first last |