AltME groups: search

might want to get me in the loop when that happens (layout work)... 
by then I should be delving into R3, so I'd be able to contribute 
experience... not just theory ;-) ... 

I've been designing and evaluating many (I mean dozens) of auto layout 
engines thru the years...

I don't think there are many known GC bugs. The largest scripts run 
yet are those of VID3.4 (around 50-100 kb) and they are fairly stable. 
No leaks have been found yet, but we aren't yet looking very hard 
for those.

The problem is that most of the code written in R3 has been written 
by people who have a good idea of the internals, who know what is 
optimal and what is not. This means that the code tends to more heavily 
represent good code techniques and practices - thus, those code patterns 
are more thoroughly tested and stable. What hasn't been as tested 
as much is bad or erroneous code: Some of that can still crash R3 
at this point.


Fortunately, new users have been joining the fray, and many of them 
are not aware of the internals or best practices. Or in Ladislav's 
case, exhaustively thorough in their testing coverage. Because of 
this R3 is much more stable than it was a month ago :)

If you search curecode.org for [gc] or [garbage collection[ there 
are very few bug reports.

Maybe it is time for someone to step up and try some serious stress 
tests.

I'll be using modules if possible.   an earlier version of R3 just 
crashed when trying to allocate a single node... we'll see.

is there a page which explains various optimisations one can do to 
R2 code to allow it to take advantage of newer and faster functions 
in R3?

I've just finished helping the plumber install a new submersible 
pump in my 50 meter deep well, changed all the electricals too... 
I didn't have water for the last 4 days... 


now I can give myself a rare treat.  taking the rest of the day off 
today, so I can do my things.... and that includes one "fun" project... 
usually a short project that I've been putting off of a long time... 
today its liquid/R3  :-)

You are quick with the bug analysis!


Not entirely sure why you consider it not a bug. Recast this way, 
it looks a horrible problem....
   for n 1 10 1 [print n a: mold system]
....It gets slower and slower and then dies.

...And the I may need a new session as:
  b: mold system
now does not have enough memory.

also the "g" command of devbase doesn't seem to work when #xxxx is 
in messages, but it works for curecode and html.

I actually like devbase.  the direct number navigation is quite possible. 
 I can just type 14   and go to R3 section directly wherever I am... 
that is very cool.

If you feel like adding a feature, go ahead, and post it to curecode. 
Carl probably prefers 1-2 line fixes, though.

Sunanda, the reason it's not a bug is because for every iteration, 
'a is set to mold system, and mold system includes the previous value 
of 'a from the previous iteration, as a string. So that means that 
every iteration is the length of the rest of the system, plus the 
length of the previous 'a times the number of visible references 
to it. Since there are 4 visible references to the collection of 
global words, this means that the growth is exponential, and of a 
larger exponent than R2 (which has only one visible reference to 
the global words, so it just doubles).


The way to prevent the exponential growth is to assign none to 'a, 
or unset 'a, before you mold the system again.

I do everything and its not in the extensions list, but strangely, 
it is working, since clicking on a liquid.r3 loads it properly.


what is even stranger is that I scanned the registry and its not 
there either!

its funny its sooo close to slim ... and slim is over 5 years old 
;-)

Well, some of the module capabilities aren't done yet (as I mentioned 
above), mostly because most of the system hasn't been converted to 
modules yet. One of the current gotchas is that system/contexts/current, 
system/contexts/system, system/contexts/exports, and system/words 
are all the same object. In the final module system, the first three 
should be separate contexts and system/words should be gone (it is 
now an alias for system/contexts/current).

The requirements for a module system in REBOL are pretty much defined 
by the task and the language semantics, and those haven't changed 
much in 5 years. It's not surprising there are similarities :)

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

this would be:

import/only 'libname [funcname]


where funcname must also be in export, so there is two sided restriction 
... was is available, and what is needed.

or using only one feature from a newer version of a library and all 
the rest from the older one, cause the update isn't compatible... 
that should be allowed.

and I'm like you and pekr... I won't stop whinning about it until 
I get it  ;-)

One thing to remember is that simplicity is a real value here. We 
need to make sure that any features we add integrate well with the 
rest, and don't create a burden on the programmer. Any setting that 
you can make is a setting that you will have to decide whether you 
need to make, so that adds to the development overhead.

We already have an /only for IMPORT, and wouldn't need it for this 
purpose - adding the words block to the Needs would be enough.

Do you know the R2 SDK source well enough to know whether the Needs 
header is handled by mezzanine code in R2? And where?

python give you the file name and the normal error after... so you 
know where that happened.

So it was a load error then? Interesting that it would return that 
error - I've never seen the like, and modules and scripts are loaded 
the same, with the same code even.

Well, LOAD loads scripts and modules alike. Where was the mismatched 
", header or code?

even if its being loaded from different contexts.   

I tried importing vprint in main app and within liquid module... 
I get an "assertation failed" error.

Have you tried renaming the file to %vprint.r, giving it a Name: 
'vprint header, and importing it lilke Needs: [vprint] or IMPORT 
'vprint ?

although its possible that import copies and rebinds each import 
to the current context, so that its

Think I found an error in IMPORT - a <= where it should be a <, and 
a >= where it should be a >. I think the file thing shouldn't affect 
it.

You want the module to be loaded and done once, but imported twice. 
Doing the module code more than once wouldd usually be bad.

shared and distinct/copied modules should both be supported.  right 
now I am not sure which one R3 does but, it doesn't provide the capabilities 
to do both, AFAICT.

strange bug... If I only
 do %vprint.r3

in the module and try to use a function from vprint, I get an error:

vprint loaded
** Script error: von word is not bound to a context

** Where: do applier make if import catch if either either do begin 
do
** Near: do body obj

vprint loaded
 is a probe statement executed within the vprint.r3 file

OK, got it. If you import a module the first time and it has a name 
header it gets added to the registry - it doesn't matter whether 
it is imported by word or file.  However, any subsequent import of 
the same module by word will reuse the module - if you reimport by 
file it is reloaded (there is a bug in IMPORT too, so the new displaces 
the old even if they are the same version). I'm going to have to 
rethink the flow here.

If I get this, it means that  DO is always global, and the only way 
to trap it, is for the module to isolate the global context from 
any code it executes.

No, DO is always relative to the current context and there is no 
global context. And you can switch current contexts, though that 
mechanism isn't fully implemented yet.

And well into it it is :)

I have been playing with converting some R2 scripts to R3.

And I am buiding a perhaps useful list of the things that need to 
change....eg:
      r2  allows: xor 1 2
      r3  either: 1 xor 2
              or: xor~ 1 2
Where would be a good place to start a list like that?

...exactly like (+ 3 4), which is not officially supported too, AFAIK. 
the supported way is (add 3 4) and always has been

I know R3 will have threading ... this is some video that digs into 
pythons implementation .. and shows how not to do threading mostly 
... http://blip.tv/file/2232410

the guy tried to run a long-running-cpu-intensive-func 2 times one 
after another, and in two native threads (on 2core cpu) that python 
supports and running it in threads took 1.8 more time than running 
it one after another

(I woud be more interested in rebol having green cooperative threads 
anyway, and if you need real multi-cpu concurrency there can be normal 
processes and message passing between (which can be made on top of 
ordinary rebol anway)

I think erlang concurrency model is higher level model and could 
be build on top of cooperative threading + os process (or thread) 
communication. Specific for erlangs model is that you can have 1000s 
of these processes that communicate with message passing. There each 
"object" is a process.. etc..  I don't know if I want exactly that 
(although I would love it also) but maybe more low level concurrency 
"enabler" where different such models can be build upon. There are 
many ways of doing actors (like native erlang (with one way messages/mailboxes), 
python's lib Kamaelia (with channels), java's lib Kilim..) and other 
things for concurreny..

Thanks.Ladislav....I don't particularly mind _why_ R3 is incompatible 
with _R2_. Forward compatibility would have been nice, but that discussion 
ended long ago with the decision not to be.


What I think we need now is to start work on a  migration guide, 
so we do not all need to stumble across the gotchas.....It may also 
help debug R3 [some reported changes may turn out to be accidental 
and fixable].


Hence my question about where would be a good place for us to start 
sharing migration hints and tips.

janko, I have been using multi CPUs machines for 15 years In 3D applications 
and you'll be surprised to know that none of them have yet to use 
two cpus for anything else than image rendering.  its because management 
of the cores generally takes as much resources than the processing 
itself.


in general, if the same processing algorythm, running multi-threaded 
is less than 1.5 times slower than two concurrent, independent tasks, 
you can start to say that the implementation is well designed, it 
rarely is better than 1.25x slower.


some algorythms and datastructures are much better suited at being 
parralelized though, and software built from scratch to support it 
will always be better at it then when its converted to multi-threading.

brianH, the isolate: true isn't documented in docbase, and its not 
working in my script, which leaves me to think that it was left out 
in public releases.

and only those from the available export list can be chosen...  so 
you have a double restriction.

what can be exported AND what you need imported.

and that is the core reason for the existence of SLIM.

slim also allows you to rename the words AS you are importing them, 
solving the name clashing cleanly and obviously.  This is very usefull 
when you are using frequently updated libs.  and is even more usefull 
when those libs aren't readily editable. (encrypted, compressed, 
etc)

in an app I tried to build using R2 a single picture took 40MB.  
I need to edit 10000 of them and output them in a picture that take 
about 1GB of space.  saving 10kb... really I could care less.

I was finally able to work around the bug.  :-)
so convertion can continue for now


but the workaround will become impossible to apply at some point. 
its too low-level a problem to be properly addressed in every single 
opportunity... and its an ugly fix.

and multiple depths

I also vote for the module system to support the ability to restrict 
what you import, and SLiM's ability to rename words on import (and 
prefix them) is very nice.

I reviewed and put comments in your vprint tickets. In both cases 
the bug is caused by code *in* %vprint.r3, not the code calling it.

In some cases the particular bug generated indicates a lack of bounds 
checking, and that is considered bad. However, it is the lack of 
bounds checking that makes it bad, not generating the wrong error.

why does DOing the exact same script, generate the proper error in 
the main app and generate a bogus error when DOne from a module... 
that is the problem.

And I still can't diagnose bug#928 without at least the header of 
%vprint.r3 - we have to have something testable.

There is an error in the import process, but modules loaded by filename 
are actually loaded each time. If the module has a name header then 
only the first import works properly. Every subsequent import by 
filename will be a logic error. However, you can import a named module 
the first time with a filename and then use the name for all subsequent 
imports with no difficulty.


If the module is not named and specifically designed to be loaded 
multiple times, then cool, you can do so.

If the module isn't already loaded then specifying it by name generates 
the filename by adding .r to the end and checking import-paths.

ok, so far it seems strickly related to file based import... specifically, 
when it tries to load the file a second time.  it raises the assertion 
crash.


reloading a module can be needed... it was changed, for example, 
and you want to allow run-time updates, cause your ip ports must 
not be closed.

In theory, runtime updates should be version-triggered. The init 
code could in theory check for a prior version and migratee the data.

I could use a minimal header and code block of a module that triggers 
the assertion crash on reimport by filename (bug#923).

Justt something to trace and test with.

I just uploaded an VERY minimal module and application with 3 imports... 
the 2 initial are by name and are fine, the third is by file and 
it crashes.

That's what I thought - it's named. You are only supposed to import 
named modules once per version - subsequent imports are to be by 
name. New versions are supposed to displace the old, and that might 
be where the crash is. This will be interesting to trace.

OK, I just looked at bug#924 and now get what you want to do. It's 
not a bug, it's by design. The code block of a module is bound before 
the block starts executing. You can't define new words in the module's 
context unless those new words are defined in imported modules or 
in the code itself at the top level, or anywhere in the code if the 
module is isolated.

Not really. They are (using a hack), but the binding of the code 
block is done after the imports are processed and before the code 
block starts executing. Once the code block starts executing the 
module context has already been defined. REBOL's evaluation and binding 
rules preclude any automatic rebinding.

but the word exists in the module before the script is done.... its 
just not set yet... so it should be bound in the module and the script 
sets the value, since its running in the context of the module.

what you are saying is that for modules, we need to start declaring 
words?  not very rebolish. 


 I have to do so in slim to keep words local to the calling context, 
 but I would have tought that modules would do so automatically since 
 they replace the global context.

 any new word in the root of the spec block of the module should be 
 added to the module's context and set to unset! just like R2's global 
 context does.

Any set-word in the top-level of the module's code block is added 
to the module's context before the module code runs, just like an 
object. If you isolate the module, every word in the module's code 
block and all nested blocks, parens and paths are added to the module's 
context. The only words you need to "declare" are the exported words.

The bug#928 should be dismissed, marked as "not a bug", and left 
there for future reference. Thanks for helping document R3 :)

Not totally. It is useful in non-module scripts, and useful for scripts 
done for effect rather than for loading functions.

Apples idea how to do real concurrency (on multicore) .. http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf
-- it seems to be based on something like closures (or blocks from 
smalltalk)  -- it seems simple and clean idea

thanks .. I am not on R3 chat. I don't use R3 and R2 has enough secrets 
to discover for me still

Here is a great example code using GrandCentral: "DispatchWebServer"

from the description: "A web server that uses one queue per HTTP 
connection. Supports HTTP pipelining and on-the-fly compression. 
Also shows use of dispatch-style signal and vnode event handling."

https://developer.apple.com/snowleopard/library/samplecode/DispatchWebServer/index.html
(ADC account needed)
Whoever is doing R3 on OS X, should have a look 8-)

Will .. that would be really interesting to look at as GC looks very 
interesting and minimal in concepts.. to bad I am not in ADC :(

Pekr, I have had the HTC touch for a year and a half...been a little 
disappointed. I hope the newer versions are a bit better but I'm 
not sure if its the hardware or windows mobile that most disappoints...
HAve you seen teh new palm pre? It looks interesting!

If r3 was up and running on htc touch I think I would overlook alot 
of my issues with it...

no, not yet, and I have no plan to support proprietary "OS" as PalmPre 
is. It allows some kind of web like development. OTOH I haven't studies 
it properly yet. I am quite disappointed by Android - it is a let-down 
for me, at least for what I saw on HTC devices - just hyped because 
of Google, nothing special ...

What were your issues? It is clearly not as smooth as iPhone is in 
operation. This is mostly because of capacitative vs resistive touch 
screen. I needed few days to make ma touch navigation more solid. 
Overall it feels more sluggish. But TouchFlo3D version 2 is quite 
snappier and I would not probably buy any Windows Mobile without 
that add-on.

... and yes, it might be the problem of Windows, because how is that 
iPhone has relatively slower HW, yet feels speedier?

Yay! I haven't been able to review the ROUND and RANDOM tickets since 
the functions were being rewritten - this should help.

After reviewing the current state of the R3 module system, here is 
the state of what is implemented so far:
- Dependencies
- Encapsulation
- Explicit exports to the system exports
- Implicit import of the system exports

And here is what is not implemented so far:

- Explicit imports, even just limiting imported words to those in 
the dependencies

- Distinguishing exports for explicit import from the system exports
- Access controls for the system exports


It will not be possible to implement what is not currently implemented 
until the mezzanines and natives are put into modules. However, what 
is implemented so far is enough to start the process of putting the 
system code into modules. Further work on the module system (except 
bug fixes) and any preprocessor will have to wait until the system 
code modularization is done.

Yes, but making it native might be a good idea. I call this function 
a lot and with a lot of numbers while filling input-forms.

can't download new alpha, tried xy times and still receiving timeouts 
....

Specific formatting is always a bit of a problem, because everyone 
needs it, they need it to be fast, they need it to be consistent, 
and they need it to be completely different from what other people 
need. Personal preferences, industry standards, local standards, 
none agree. Fortunately in R3 native doesn't have to mean built-in 
or standardized.

to-pair [1 2] not working is a bug, btw. Has a ticket and everything.

yeah, I am really satisfied with last few months of developments, 
and I think that the community in overall is, as Carl is doing mostly 
Core stuff, and not GUI. R3 is getting more and more robust and consistent, 
although there is still some way to go. I can feel that we are getting 
more R3 fixes per month, than we get for R2 in last decade :-)

Yes -- I am hitting bugs, reporting them on curecode and often seeing 
them fixed in just a few days. It's a good time to be evaluating 
R3.

if we want the hierarchy to be linearly ordered by fineness, then 
the equality should compare just spelling of words, the second one 
- finer and non-existent yet, should compare spelling and binding, 
the third one should compare spelling + binding + datatype (can be 
strict-equal?), the fourth one is not that necessary in this case

BrianH: if binary and string types are more divorced, what do we 
gain in particular?

Ladislav, just checked your SAME? criticisms from the wiki against 
R3, and only the date! transitivity thing still applies.

Struct! is not implemented, nor is denomination in money!. Closed 
ports are not errors and decimals are fixed. Unset and error are 
still not values. The only thing left is the date! zones and the 
type-ignorant any-word comparisons.

Cool - we need as much help as we can get. I'm glad he participates 
in the chat too, and his testing has been very helpful.

I think I ran into him before (may be virtually), I remember him 
as a very kind and nice person.

that is unless you consider a 100x (thats 10000%) increase in RAM 
usage and script slowdown acceptable.

I have been trying to think think it through - there are advantages 
and disadvantages to either way. It is harder to undo a copy than 
not...

(and ram too)

And the returned words are bound to the object.

WORDS-OF works on any-object!, any-function! and map! too, though 
it's only bound to any-object!.