AltME groups: search

Use the needs header to load the modules you need and you can be 
sure they'll be included. As for which functions will be mezzanine, 
that is still in question for many functions. If you want to make 
sure that your favorites are there, oparticipate in the discussion.

load %some-image.png


not even assigned once... causes a permanent memory use in the last 
version of which I had to use huge images.  I ended up using image 
magic which was able to use the equivalent of 20 GBs of image data 
in a single 75 minute composition.

that's quite a problem, but is it possible to allocate space and 
load new image data into that location?

Diffferent, but related......memory may be deallocated within REBOL's 
sphere of influence one the items have no more references; but it 
is not (it seems) dellocated back to the opsys until the REBOL thread 
closes.


That can create several problems ..... eg an application that uses 
a huge peak memory load at startup, and would like to hand it back 
for the next 8 hours of running. It's all in the arena of efficient 
memory management.

There is a difference between loading image using 'load function 
and loading using 'load-image function (which is used by VID). The 
second one stares data in cache.

And I see no problem with the first one:
>> recycle stats
== 4384079
>> x: load %/f/IMG_0783.jpg
== make image! [1024x768 #{
4E707A59767C5D7172565F5A4D4E464E4A3F554D4258504558494254453E
4F40394E3D364A373148332E4A35304F3A35483E34...
>> recycle stats
== 7531902
>> x: none
== none
>> recycle stats
== 4384079
>> load %/f/IMG_0783.jpg
== make image! [1024x768 #{
4E707A59767C5D7172565F5A4D4E464E4A3F554D4258504558494254453E
4F40394E3D364A373148332E4A35304F3A35483E34...
>> recycle stats
== 7531950
>> recycle stats
== 4384127

Maxim, do you know this:
>> view layout [image %/f/IMG_0783.jpg]
>> second second :load-image
== [%/f/IMG_0783.jpg make image! [1024x768 #{
4E707A59767C5D7172565F5A4D4E464E4A3F554D4258504558494254453E
4F40394E3D364A373148332E...

?? load-image

oldes... no I didn't know this.

but I never let view load images on its own, I always control that. 
 I didn't even know about load-image  ;-)

oldes, about the load ... its not totally obvious why sometimes the 
images stay stuck in ram... but in this case it was huge png images. 
 and I did every recycle trick I new of... I tried solving this for 
2 hours... but nothing worked... not even allocating other stuff, 
and freeing it, to make sure the GC really did do a cleanup (in case 
is was count based).

It may not seem obvious, but 

	view layout [image %file.png]

does make use of LOAD-IMAGE, as Oldes pointed out.
Here is where the IMAGE style does it:

	print mold get in svv/vid-styles/image/multi 'file

on windows, the detail is that even the OS uses swapable RAM by default. 
 there is registry setting to prevent this, and it makes a hell of 
a big difference in windows itself.  when the machine is under load, 
the OS stays responsive, as opposed to becoming a hog.

Yes, that's correct.  My gui doesn't block while I wait for FF to 
start up and load the page I want.

To use it, double click on the blank canvas to create nodes, and 
double click on nodes to edit them.


Drag arrows from one node to another by click and drag from the left 
bottom corner.

Control-L to load a new map

Control-S to save a new map

Is your code in strings? Because otherwise you can just use LOAD 
to syntax check your program..

false == (some magic trick) first load "[any]"
true == (same magic trick) first append [] in system/words 'any


the first is just an unbound word, using the string just makes this 
explicit beyond doubt.
the second is the actual word func. added to a block.

maybe I can just do this :

same? bound? first load "[any]" system/words 

 and assume I'm not actually using global words in my blocks...

to-block, do like LOAD, except it doesn't bound the words in the 
global context

Maxim, BOUND? doesn't bind words to the global context - that was 
done by LOAD. Try this:
>> bound? first to-block "a"
== none

load is the core culprit here.  I didn't realize that all my rules 
where being bound at application load time, since every word is created 
by load initially.

That was one of the first things changed in R3. If need be you write 
your own loader for R2 that uses TO-BLOCK and then does the binding 
itself - LOAD in R3 is a mezzanine that does the same.

I see no bugs.

REDUCE,  acts on blocks, nothing else.


TO-PAREN and TO-BLOCK on strings, act like LOAD, but don't bound 
the result in any context.


Both of them have well known behavior. It's perhaps a lack of good 
documentation but no bugs.

spell: func [ check [string!]
	/local req result suggestions
][
	req: reform compose copy [ 

  <spellrequest textalreadyclipped="0" ignoredups="1" ignoredigits="1" 
  ignoreallcaps="0"> 
		<text> (check)  </text> </spellrequest> 
	]

 result: load/markup read/custom https://www.google.com/tbproxy/spell
 reduce [ 'POST req ]

 either parse result [ tag! tag! tag! set suggestions string! tag! 
 tag! end ][
		parse suggestions none
	] [ none ]
]

>> spell "rebol"
connecting to: www.google.com
== ["reboil" "rebel" "reboils" "Reebok" "rebook"]

Well, in R3 we don't have pointers or pointer arithmetic, you can't 
just reference arbitrary memory, all data has to be either literal 
or returned from a function. Words aren't bound by default, they 
are bound by the LOAD and DO mezzanine code, which can easily be 
replaced for your sandboxed code. The code can run in an isolated 
module with careful control of its imports.

As I recall, MV isn't possible due to limitations in R2 ports, but 
I may be wrong. You would have to load the entire file into memory 
and save it at the destination. If there already is a MV function, 
then I'm wrong.

Is it intended that some binaries read with LOAD, should return an 
empty block? REBOL/View 2.7.6 here.

Interesting:

>> load read/binary %file.dat
== #{
0000100000001D81000076100000766700007D7E00007F6C00007FB300007FF2
0000805B000080CE00008166000081B100008293000082F10000834A0000...
>> load %file.dat
== [
]

LOAD in R2 has several bugs and design flaws - not sure which is 
which - which probably can't be fixed due to compatibility.

Thanks for the input Brian. I've spent many an hour trying to figure 
out how "load" behaves.

So did I, when I was writing LOAD for R3, fixing the aforementioned 
bugs and design flaws.

Working on LOAD this week, actually. Already fixed one bug earlier, 
now working on a tricky blog request.

load in R2 has even returned a word! datatype to me !

I think it's often more preferable to parse the data rather than 
load it ...

LOAD should be a quick way to tell whether I'm loading REBOL valid 
data or not. Returning an empty block for an unknown 1 MB binary 
isn't appropriate, because the outcome is suddenly loadable.

This is how LOAD can be a mezzanine, btw, and still be called by 
DO. And it's how the module system can be mostly mezzanine too.

remember that molding a string actually escapes special chars, so 
you can 'LOAD it back intact.

REBOL can LOAD a script from file, which holds real newlines, not 
escaped ones. So it's not possible to produce a string including 
newlines, when using MOLD?

Geomol, no, REBOL cannot load your S string...

>> s: {"^/"}
== {"
}
>> load s
** Syntax Error: Invalid string -- 
** Near: (line 1) "

Gabriele, interesting. My understanding of LOAD changed a bit. Loading 
a script... hm

>> s: {^{1
{        2^}}
== "{1^/2}"
>> t: mold {1
{    2}
== {"1^^/2"}
>> length? s
== 5
>> length? t
== 6
>> length? load s
== 3
>> length? load t
== 3

Nah, my understanding of load didn't change. I can't have a string 
with double quotes across lines. But I still can't see, why my t 
get the extra hat (^).

Well, as I understand MOLD, it will create a string, we can LOAD 
in again. If the original holds a newline outside any string, it 
should just be kept as a newline, shouldn't it? REBOL can LOAD newlines, 
which are seen as white space (like the space character). Maybe tab 
is better to illustrate, what I mean:

>> mold {^-}
== {"^^-"}


I get a result string holding 4 characters, while 3 is good enough. 
When I LOAD this result, the two characters #"^^" and #"-" get changed 
into one tab. Why? And why does MOLD produce 4 characters in the 
first place?

Should LOADing a string be the same, as if I entered the content 
of the string at the prompt? I would expect that. If I write:

>> "^^-"

I entered a string consisting of 2 chars. So loding this:

>> load {"^^-"}

should be the same, 2 characters, but it isn't.

And I see no problem with my way:

>> length? {^{^/^}}
== 3
>> load {^{^/^}}
== "^/"

When you
>> load {"^^-"}

you are loading the string twice, the first time when you are loading 
{"^^-"} and the second time when you are loading "^-". Each round 
of loading resolves another set of escaping.

So maybe I should ask, why do LOAD double-load?

It doesn't. It loads once (at the command line), then *you* load 
a second time explicitly.

Keep in mind that you are already loading a script: {load {"^^-"}}. 
And then executing that script, which loads another script: "^-".

It was the same in R2, though LOAD was native (and incredibly buggy) 
instead of mezzanine (and more capable).

(based on rendering 3D animations which required 4GB of swap file 
, just to load a scene  ;-)

Graham... LOAD does the escaping, READ does not. does this help? 
MOLD also does the escaping, so if you PROBE at the console you see 
that, but it has nothing to do with what is actually in memory.

Those who don't use LOAD are condemned to reinvent it, badly :)

just BTW, an expression like

    is-email-addr: get bind load "email?" bind? 'system

can be expressed using a shorter form

    is-email-addr: get bind load "email?" 'system

, which is, in fact, the same, as:

    is-email-addr: get load "email?"

load

thing is load isn't the counterpart to mold.  'DO is.   and even 
then, even MOLD/ALL isn't a real serialization because shared objects, 
or series aren't shared anymore.


although they go a long way, and I have been using them extensively 
in many tools, MOLD & MOLD/ALL are just helpers, destined for advanced 
users who have very special requirements.

just added an (very succinct) extended serialization example which 
would allow us to basically fix all the MOLD issues on LOAD directly. 
 it could be the basis for rebin, which could just be a compressed 
version of the source version to keep it (very) small.

Max, I had a specific issue in mind: (pre)processing of REBOL scripts. 
In that case, you we not need to worry about such issues as binding, 
shared objects, etc. I am quite comfotable with MOLD, since it does 
not look like a gotcha to me (not that I want to repeat that "MOLD 
is not a counterpart to LOAD" mantra), but SAVE clearly *is* a gotcha, 
since nobody sane would expect it to "distort" REBOL script when 
saving REBOL code obtained as a result of LOAD.

Are you kidding? Try to load any script and save it

Maxim:
>> mold/all load "foo: none"
== "[foo: none^/]"
no distortion here

#[true]

 is a normal REBOL syntax, since REBOL is a language, and LOAD as 
 well as Lad recognize it.

but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur. 

this is a big detail, which most REBOLers do not grasp.


the litteral notation allows you to load items AS data, not as DO 
dialect source code.


I guess what could be done is to remove the /ALL refinement and add 
a new refinement which forces the non /serialized format.  but that 
makes SAVE work opposite of other serialization handling ... which 
is why I'm not sure that is such a good thing.

but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur.
 - this looks like a confused statement to me. Example:

mold/all load "true" ; == "true"
mold/all load "#[true]"; == "#[true]"

There is no rocket science involved.

and even then, I don't LOAD scripts because we loose all the comments, 
so I pretty much always use LOAD/next, & string parsing to process 
REBOL source scripts.

mentioning the perceived symmetry to mold and mold/all is kind of 
evading the argument. ladislav is arguing that SAVE should be useful 
with respect to LOAD. nothing stops us from defining SAVE as WRITE 
... MOLD/ALL ..., and there is no necessity to hold up this perceived 
symmetry.

>> save/all %foo.r load/all "foo: func [x] [x * x] foo 42"
>> do %foo.r
Script: "Untitled" Version: none Date: none
== 1764

works pretty well!

and that's the whole point. if you load a script and then save it, 
the original script should be affected as little as possible

LOAD

i.e. everything LOAD accepts

LOAD accepts a lot of stuff that doesn't match this or that dialect's 
semantic model.

And based on that, the problem is: load + save does not preserve 
the original data correctly

Ladislav, a clarification: The DED has a semantic model, but it doesn't 
exactly match the in-memory model. And there is currently no function 
that can generate a serialized form of the in-memory model, and no 
function that can recreate the in-memory model from a serialized 
form (in this case "serialized" being used in its accepted meaning 
rather than the REBOL "serialized syntax" term). MOLD and MOLD/all 
are just approximate, as is LOAD. DO is a bit more accurate, but 
there is no function that can generate DO code from *all* in-memory 
structures, just some of them; the rest currently have to be written 
manually. So what we need is a function that does a better job of 
serializing the in-memory data model, and probably a new syntax to 
represent it.

the best argument I heard in this discussion _against_ the sequence 
of load + save behaving as transparently as possible is that this 
is not at all intended in the first place! except, the argument gues, 
the intended design is for save to be symmetric to mold.

So what we need is a function that does a better job of serializing 
the in-memory data model, and probably a new syntax to represent 
it.

 - actually not, as I have no problem to demonstrate, since the goal 
 of script preprocessing (which is the subject of this discussion) 
 can be reasonably achieved using the LOAD and SAVE/ALL pair.

We are only concernce with this subset of data structures and we 
see that LOAD + SAVE in sequence does not adequately preserve even 
those.

And the argument is that a pair of functions with the names of LOAD 
and SAVE which pretty much cry *duality* is to be considered harmful 
if they willingly violate their implied duality.

Taking the decimal! type as an example, the DED syntax (what LOAD 
can handle) can accept a wider range of decimals than can be represented 
in-memory. Those that can't be represented directly in memory are 
approximated. Since those approxiimations tend to happen in the 16th 
to 17th digits, they can be "undone" by ignoring those digits in 
the "friendly" output.

If you want to consider LOAD and SAVE not being a duality to be harmful, 
go ahead, considerations like that are a matter of opinion.

Reapproximation for MOLD, no approximation for MOLD/all, approximation 
depends on the digits for LOAD, at least for decimals.

Ladislav, it was just an example to illustrate that the abstract 
REBOL that is accepted by LOAD doesn't exactly represent the real 
REBOL in memory. But it does represent enough to do source processing 
by a preprocessor.

If you want to consider LOAD and SAVE not being a duality to be harmful, 
go ahead, considerations like that are a matter of opinion.

As a matter of fact, LOAD and SAVE/all form a far better duality 
as far as REBOL source is concerned. So Ladislav and I argued that 
making /all the default for SAVE would be a sensible thing to do.

Sure, that's why we are discussing it at all. Besides getting mightily 
side-tracked in semantic debates that do mostly not pertain to this 
issue, to only argument against this suggestion I heard was that 
SAVE should behave symmetrically to MOLD, not dually to LOAD.

Fair enough. So your take is that LOAD/SAVE forms no duality because 
of MOLD is supposed to do "developer pretty printing" but for absolute 
newbie developers, not for developers familiar with e.g. #[] syntax.

The primary purpose of SAVE is to save scripts that are to later 
be processed by DO.

 - weird, i always use save and load to save and load data. but, even 
 if that was the case, save/all would work just as well, so this is 
 a silly argument.

Hmm... I recall saving rebol objects with save/all and not being 
able to load them again properly

Graham: show me ONE example of something you can LOAD but then breaks 
when you SAVE/ALL it back.

...and in that case we have the LOAD function, and its counterpart 
should be the SAVE/ALL function, not the SAVE function (that is essentially 
what I wanted to underline/document somewhere)

Yes, a good point.  But, and furthermore, even using LOAD instead 
of LOAD/all can be a problem for users due to its method of removing 
the outer block. An odd problem.

consistency leads to a lower cognitive load for the programmer

my-image/image:  make image! 60x80 load %./Photos/test.jpg show my-image

iam stupid ;-)    my-image/image: load-image %./Photos/test.jpg show 
my-image

Replace 'load-image with 'load unless you want to cache the image.

Hi, 


Am just moving over here from TCL-land and would like to try RebGUI. 
However, there seems to be two versions: one downloadable from the 
Dobeash site (rel #117) and on resident in SVN (#218).


Which is the one with which to go; and if the version on SVN, what 
is the method to down load an use?

Any assistance would be appreciated.

Rick

I see bugs already. LAUNCH could use a revamp like LOAD.

ah, load-plugin .... what a bad name once again. Why load or import 
does not handle it internally? ('import is used in the blog article)

I Don't write it back.
Summary:
We can't serialize vectors to save/load them into files.
We need decisions.

Designing vectors not serializable from the start was an error to 
my mind.

Quick discussion needed, and here because more people need to chime 
in:


There is a proposal to change the name of the MAP function to MAP-EACH. 
Here's why:

- There's a map! type, and this function is unrelated - except in 
CS theoretical terms, which is why we suggest the name MAP-EACH.

- The other functions that have the name of a type without the ! 
are constructors for that type. The map! type could use one.
- This function is behaviorily one of the *EACH family already.

- This is *not* the functional language map function, and it might 
be good to emphasize that...


In functional languages, functions like map take functions as parameters. 
However, such languages tend to be compiled and the function values 
they take are constructed ahead of time. Since REBOL is interpreted 
and functions are created at runtime, that kind of code pattern tends 
to be inefficient. That is why REBOL control and loop functions tend 
to take blocks instead, and have any argument words to those blocks 
as a separate parameter: It's much more efficient that way.


There is precedent: The REBOL function that corresponds to the functional-langage 
filter function is REMOVE-EACH.


We ask this question now because now is the time to make the change, 
if ever. Not many functions in R3 use MAP yet (the only one I can 
think of off the top of my head is LOAD). This will change when we 
do a hand-optimization pass of the mezzanines, and it will definitely 
be too late once we hit beta.


What do you all think? Please chime in in the next couple days if 
you can (and have an opinion).

Two questions:
1.  is there a way to load-gui from local file ?
2. How is unicode in rebol3 working ?  (is it working ? ) :)