AltME groups: search

Ladislav has rank 70 .. and so either Carl reinstituted the edit 
facility just after ladislav tested it .. or it's broken

Yes. I want to browse the words really, and look at the examples 
too. Thanks.

IMO focus should be now on bug-fixing and closing open tickets. There 
is still some smaller things to do on the AGG side. And than get 
a V1.0 out of the door. Because I don't see any cause to not make 
an offical V1 release of R3 anymore. It's mostly ready for prime 
time.

I posted in R3-GUI as I consider it being "your group" :-) Well, 
1-2 month bug-fixing could be usefull, but I know ppl - noone will 
consider R3 ready, unless the basic infrastructure is in-place. And 
not having tasking/IPC is one big handicap - e.g. Doc will surely 
not start the Cheyenne transition (if he will port it at all) ..... 
that's how I feel about it. 'Call needs to be implemented too, or 
R3 stays in isolation for system related scripting. Your aproach 
limits R3 to only GUI realated usage ... if we are rushing to have 
R3 1.0 stamp on it, then priorities, or simply target feature-set 
should be discussed, and set ....

until R3 supports threads, I don't think we should consider it beta. 
 this is too big a hole in 2010 for it to be sidestepped and ignored.

adding threads *could* have far reaching implications in many little 
areas of R3.  I woudn't want to start a big project and then realize 
that its broken after a thread enabled release.

I just wonder, why Carl regards it being a preliminary release, and 
that the concept has yet to be proven - is there any other way than 
using events? :-)

There may be something else he wants to do. He has mentioned briefly 
a method for creating MVC based GUIs using ports and events, thus 
making that a low-level feature. This would require a small bit of 
code, but I don't know if it affects tasking. I don't know what else 
that means, because that's all he said about that.

Today I read about the MUI (Amiga). Some ppl still consider it being 
kind of good aproach to GUIs, and now AROS is getting it too. I mean 
- if Carl wants to look at some low-level framework, MUI might be 
the system to study ...

I really think, that the last big element missing is tasking/IPC 
interfacing. As Max said - it might influence other subsystems, so 
I think that such stuff should follow callbacks ... and then adding 
features here or there would be OK for 3.1, 3.2, etc. Maybe one other 
thing - rework decoders/encoders to ports asap, before ppl write 
some codecs to later find them useless ...

btw - so we have got callbacks. As I can't see any real examples 
(probably too early and everybody busy), could anyone share an idea, 
how are they usefull? I know that "some" external libraries might 
require them, but any concrete example?

OpenGL GLUT events are driven by callbacks, which we can now push 
into REBOL "user space".


so for example, you provide an on-key() or on-mouse-down() callback, 
and you receive the events, directly at the function.

all this nice stuff can be seen as a real ... enabler. I vote for 
the tasking/IPC being next, changing codecs to streamed port model, 
and then marking R3 Core a beta .... but not sooner ....

yep, but I mean that the network schemes are important and should 
be part of the beta phase.  we don't have much working right now.

I don't see tasks as that important as callbacks. Can someone please 
make a clear business-case for tasks? I know it's nice and helpful 
for some areas but is it mandatory?

yes... most applications now are multi-threaded if only to make them 
smoother...  the GUI in one thread, heavy lifting in another, for 
example.


async, doesn't allow you to scale, only to time slice.   you can 
still only compute on a single request at a time.

if the request needs time to finish (rendering, for example), it 
effectively blocks all async and I/O handling.

yes but you are still limited by the quantity you can process.  with 
just about every cpu out there now having at least two cores, its 
great waste.


with most of the serious apps I've done, multi-threading would have 
made things much easier or in the least smooth and interactive.  
with servers, I need not present a case, threading speaks for itself.

Ok, maybe I need to make clear that I'm not against threads. But 
IMO it's better to get something done and finished now, and release 
it. Than keep the pace and concentrate on threads on the next release.

Adrian, unfortunately that description may characterize the tasking 
model. For all its high-level features, in many ways REBOL is a low-level 
programming language. We don't have internal process separation, 
and we do have modifiability. The tricks that are done to make functional 
languages at all efficient require compilation, and we don't have 
that. Managing any of the new concurrency models requires changing 
the core semantics of the language and we aren't doing that much.

We will be able to build higher-level concurrency models in R3, but 
the core model is very low-level and requires a lot of manual management. 
I suppose that's rather REBOL-like since that can be said about binding 
and scoping as well.

None: We haven't been talking about it yet. There has been some speculation 
that PROTECTed data could be shared, and the "user context" is supposed 
to be task-specific (designed that way, not task-specific yet). But 
the PROTECT security model isn't finished yet (there are tickets 
yet to implement), and nothing has yet been done to make it tasking-friendly.

It would be expensive. And aren't we trying to make things optional 
now? It would complement DEDUPLICATE well though.

yes, I'm not sure there is a way to make it in-expensive, but I've 
stumbled onto several situations where I would like not having to 
write and test it.

If you've imported a module and then updated the module and incremented 
the version of it and then call import again this time requesting 
a newer version than has been loaded shouldn't the module be reloaded?

anyone know if R3 RENAME will allow moving files and dirs now?

Ammon, the answer is yes, without changing system/modules. The new 
module is added (and used for all new references), and the old module 
is still referenced in system/modules so the new version can migrate 
data from the old.

Then I've found a bug...  And some unexpected behaviour...

>> t: import 'test-module
>> test
0.0.1
>> t/test
0.0.1
>> t2: import/version 'test-module 0.0.2
** access error: cannot open: %test-module.r reason: none

>> t2: import/version 'test-module 0.0.2
>> test
0.0.1
>> t2/test
0.0.2



Apparently if you don't have the version available in your module 
search path then it errors out without telling you why it failed.

Yeah. The bug is that we need better errors. I am rewriting the module 
system now (more or less, I took a break for a bit). The last stage 
is reviewing the errors and getting more informative ones added to 
the error catalog.

And those asserts are incredibly confusing...


Glad to know you are working on it.  Does this mean that I don't 
need to enter any of this in CureCode?

The requested delayed modules feature ended up creating a lot of 
other features as a side effect. The new module system is much more 
powerful. And by default just as easy to use (I hope).

and windows too

It's a guru only release and very unstable, but there is a link in 
the REBOL3 Host Kit group.

it's sound like guimauve in french and it means marshmallow

I've created this function many times enough to think it should be 
standard:


; creates a string from a list of strings with human readable comma 
separation
string-list: func [blk /local out] [
	out: make string! 1000
	forall blk [
		append out form first blk

  unless tail? next blk [append out either tail? at blk 3 [" and "][", 
  "]]
	]
	out
]

string-list ["a" "b" "c"]
== "a, b and c"

I don't do this .. but I have code that processes a whole sentence 
and grammar fixes it including the above.

I've built similar funcs, but not often. Maybe it could be part of 
a formatting module, and I would give it a different name.

The output format is specific enough, and the name generic enough, 
that I wouldn't make it a standard func as is. It is useful though.

Done. And bug#1643 marked as fixed in it..

Just reading new roadmap - http://www.rebol.com/roadmap.html... 
what I don't understand is all the fuss about R3+. From the very 
beginning, I don't like the idea of putting some usefull stuff into 
additional module. E.g. - why some usefull mezzanines or protocols 
be part of the plus package? What I fear is - anything, that is optional, 
will not be a standard. I can understand that we can't include 100 
protocols probably, but talking about + package, where the only protocol 
we have is http, and even that is not fully functional, is a bit 
preliminary :-)


Interesting note about R3 DB - what is R3 DB port? Is Rebin, RIF, 
finally coming? Or did we decide to select one DB, e.g. SQLite engine, 
and include it into R3?


As for tasking - "Experiment: how far does the current R3 multitasking 
base take us?" - no experiments, please :-) Tasking/IPC is the last 
missing stone before we can claim R3 being a beta - it needs solid 
work, and I expect 1-2 months, and the same kind of impact, as Unicode 
transition, or Extension, Callbacks had :-)

Pekr, what part of "optional" means "non-standard"? It just means 
that it isn't loaded and taking up resources if you don't need it.

modules, callbacks, memory leaks in the GC, memory exceptions, IPC 
and API for inter-thread data shareing, the potential list is long.

R3 is currently undergoing open-heart surgery, with Carl deep in 
system and architecture mode... with all of the stuff fresh in his 
mind.


I think its the perfect time to overhaul the task! system and finally 
make a real architecture/API and identify,  solve,  or decide on 
the potential issues "hard issues".

what is "years of user expectations"? if you speak for you and Pekr 
saying, that R3 beta is what "your needs" are, then you are patently 
wrong, no matter you are two now

Please be so kind and do not speak for me ("whole REBOL community")

But we each have different things that are important to us. I might 
say that robust and professional integration with SQL server is key 
as I know that's stopped a number of people from using REBOL in their 
companies. I could use that as a selling point, but I don't want 
to use SQL Server myself. :-)


Other things are more important to me, but only Carl knows what he 
thinks is important for him and for REBOL.

if the task! datatype is to be part of R3... which it currently is... 
and is laden with bugs, many unknowns and limitations... either we 
rip out the concept of tasking in R3 and limit the language's appeal 
or we fix the datatype and its api.

Gregg the difference is that Tasks operate at the core level and 
imply possible GC hacks, inter extension mem management, hard to 
track stack stuff...


all things which inherently *might* force changes in core level apis 
like devices, extensions, etc.

I can't speak for Ladislav, but where I disagree about limiting the 
language's appeal is that we don't know who it's supposed to appeal 
to. It may not be you, me, and Petr at all.

There are zillions of things we want to see. Ok, and everyone wants 
something different.

And we will keep the high pace of new releases. Each one delivering 
more stuff.

Maybe something breaks existing code than. Yes, not to nice and takes 
some work but it's not killing us.

While R3 moves forward, we will use it for all our projects. Add, 
what's missing on the way and move forward.

The message that's important to all (including Lad here ;-)) is that 
R3 is useable for quite some stuff and should be used. Maybe not 
for everything yet. But you can start to use it today.

If tasks break things, yeah, than that's how it is. I take the risk, 
we adopt our code once and that's it.

And if a good task implementation takes 6 months... than it takes 
6 months and is of good quality than.

A105 is the first one to integrate our AGG code line. So, bringing 
Carls work and our work much more in sync with less hassels for new 
releases.

And yes, it's stable WRT AGG. I don't expect major architecture changes.

I'm not yet an expert, but I think that the GOB! get's converted 
to the AGG world. Hence, you can take the GOB! from Rebol and however 
you bring it on screen, just do it.

A106 is planned to have call/wait and launch/wait.

call/wait/output was (for me) the most used scenario, wrapping some 
command-line tools and obtaining the result. That way you can simply 
wrap e.g. SQLite.exe result, without the need to have proper driver 
...

Adapt Doc and Gab's async-call code.

From Carl:


License statement:  if someone makes the R2 shell.c streams work 
in R3, then we'll release it as open source in the host-kit as host-call.c 
(or host-shell.c).  And, the community can support it directly.


In other words, we'll contribute the R2 code to the R3 host project. 
(I just wanted to clarify that.)

I'm not sure it's particularly large. It seems that just interfacing 
is very difficult:


The difficulty is not inherent in the design requirements... it's 
because stdio methods are very old (as old as modern computing) and 
have been messed with (inside the OS) for such a long time.

he posted some comments from the code (I'm not allowed to repost) 
and it does not look simple.

Well, if Carl is ready to open-source R3 *fully*, I'll be more than 
happy to take that (and other) challenge(s). ;-)

Max, you still can use digit as the first char. From changelog:

The representation of numeric values (invalid word forms) is still 
supported, so usage for HTML colors or hex numbers, and conversion 
to and from tuples and integers, still works.

Should I CC it, so that someone with edit rights can correct docs? 
http://www.rebol.com/r3/docs/functions/stats.html- in R3 'stats 
no more supports /types and /pools refinements ...

.... and other refinements too :-) The text is probably a left-over 
from R2 description, whereas function description is probably auto-generated 
:-)

I've upgraded r3 to the latest version found here:

	http://www.rebol.com/r3/downloads.html

and note the following:

>> system/version
== 2.100.99.2.5
>> make gob! []
== make gob! [offset: 0x0 size: 100x100 alpha: 0]
>> source show
show undefined
>> source size-text
size-text undefined

where did View go and when will we get it back? ;)

show and size-text are natives not mezz. Without them you can't build 
a GUI.

and it's confusing the definition with a tuple somehow?

converting code to R3 isn't a piece of cake!!!  I mean real-world 
pieces of mature and optimized/tuned code... there are gotchas just 
about everywhere.

but I've now got slim working in R3  ;-)   am now working on converting 
liquid and other libs.

is there a way to tell R3 to automatically show stack information 
when errors occur (and aren't trapped)?


python allows (on by default IIRC) this and its a MUCH more usefull 
error report.

for the same reason as for Rebol... many errors don't occur in user 
code, but in mezzanines, called by user code, sometimes several deep.


knowing why and where an error occurs is usually as usefull as what 
is the error  (and often, even more).

which means I have to put exception handling in all functions... 
and even then, when an error occurs within a mezz... its not going 
to be reported there... so I won't have the stack based on its calling 
... so the end result isn't near as usefull.

after a little bit more work on translating to R3... it seems to 
be much less work than it started out to be   :-D


I've got the basics of my dataflow canvas engine working in R3 (which 
is the basis for GLASS and many other tools of mine).


most of the time spent was in fiddling around with learning the changes 
in R3 view engine itself.   this is a 40kb lib running over another 
50kb lib... and its working as-is (once I removed references to the 
word 'FACE and system/words, mostly).

ok, your compile also crashes  on my system... strange!


we need others to test this.... please, if you have a running r3 
A107 try it out so I make as precise a ticket as I can.


if it doesn't crash, download the file and try to add a few (or many) 
draw commands to it so see if it fails at some point.

Maxim, I get a crash too if I comment the first load and uncomment 
the second. This is with a107 compiled with the MS compiler.

What's the point of SYSTEM/CATALOG/ERRORS/:CATEGORY/CODE , how is 
supposed to be used and what are it's limits? 

I've noticed that you can't extend SYSTEM/CATALOG/ERRORS with your 
own error category if that is defined with an code of 997 and above 
in R3:


>> odbc: make object! [code: 996 type: "odbc error" no-handle: [""] 
cannot-connect: ["Cannot connect to" :arg1 "because" :arg2]]     
 ; define my own error category

>> extend system/catalog/errors 'odbc odbc   ; extend standard errors 

>> cause-error 'odbc 'cannot-connect ["CACHWEB Samples" "no such 
DSN"]

** odbc error: Cannot connect to "CACHWEB Samples" because "no such 
DSN"

>> system/catalog/errors/odbc/code: 997   ; too high an error code

>> cause-error 'odbc 'cannot-connect ["CACHWEB Samples" "no such 
DSN"]
** Script error: invalid argument: [
    type: err-type
    id: err-id
    arg1: first args
    arg2: second args
    arg3: third args
]
** Where: make cause-error
>> system/catalog/errors/odbc/code: 996

>> cause-error 'odbc 'cannot-connect ["CACHWEB Samples" "no such 
DSN"]   ; back to normal

** odbc error: Cannot connect to "CACHWEB Samples" because "no such 
DSN"


R2 seems to not pay attention to the error code, at least it doesn't 
choke on values of 997 and above. That limit in R3 seems to be somewhat 
arbitrary?

It isn't a protocol yet but rather has a module/function API. ODBC 
database access is working for me as a Windows only host kit extension, 
with UTF8 strings and bound parameters. I'm in code cleaning stage 
and I'm about to support SQLTables and SQLColumns catalogue API functions. 
Sadly, it won't be possible to use it with DATE! values for long 
(see curecode). And, yes, I'm thinking on supporting some ODBC errors 
in their own error category. There are no best practices known to 
me on how to do that, though.

it does and works using Aton's com lib

If you need it to be robust, and talk to mtuliple versions of Outlook 
(e.g. used by others who may have a different version), consider 
using Redemption. It is robust and well worth the money IMO.

florin, it might just be a config issue.   did you get the comlib 
to do anything within excel?  IIRC Anton's comlib has a few examples 
for excel and word.  getting that to work first will make outlook 
attempts a bit easier.

LOAD loads and binds strings except being told otherwise with /UNBOUND:

>> set load "a" 2
== 2
>> set load/unbound "a" 2
** Script error: a word is not bound to a context
** Where: set
** Near: set load/unbound "a" 6

I don't think it's especially picky the way this is.

because we now have unbind and generally much more control over the 
binding, I would have thought that auto-binding to user context wouldn't 
be such a big issue.

A refinement for SET might be very handy for the unbound scenario, 
and BrianH may chime in with the design logic to help clarify.

Maybe combined with a stack dump? That is, when you say WTF? you 
need all the help you can get. And the refinement for even more info 
would be /!. ;-)

That is very strange and makes me wonder why I haven't been tripped 
by this BTW, you're talking path notation here not refinements. With 
function refinements it seems to work as expected.

People use things at different levels of expertise ... and if there 
are enough experts around to critique their work, they will get better. 
 So, the differing programming styles seen are a reflection of Rebol's 
failure.

And complex things are complex

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

Interesting. I think that's a bug, as CLEAR's spec is as follows:

clear: make action! [[

    {Removes all values. For series, removes from current index to tail 
    and returns tail.  (Modifies)}
    series [series! port! map! gob! bitset! none!]
]]

Yes, it probably would. At least in this specific case that's quite 
possible to do. But in general it would make more sense if the flexibility 
to define and wire "native" ports would move to the hostkit completely.

Is it perhaps intentional that 'remove and hence 'clear don't work 
as 'delete is now the action! type responsible for this task?

LAUNCH is undergoing revision in R3 these days and is a mezz, not 
a native, but the problem seems not to be on the side of LAUNCH.

Now for the other binding stuff:


* SET is a low-level function that would be slowed down immensely 
by adding any refinements.

* SET does handle the unbound scenario: It triggers an error. You 
can then handle the error.

* R2 and R3 get their speed from the direct binding model. The core 
speedup of that model is that SET doesn't bind.


* LOAD in R3 is a high-level mezzanine function. It is meant to be 
as fast as possible given its purpose, but being fast is not its 
main goal; user-level flexibility is. Most of the overhead of LOAD 
is in handling all of its various options, as refinements, file extensions 
and script header settings. If you know what you are doing, you can 
always optimize your code by doing it directly instead of having 
LOAD try to figure out that is what you want to do. LOAD is not meant 
for use in tight loops.


* Henrik, ChristianE, the R3 standard answer to the question of how 
to make BIND TO-WORD "a" more efficient or friendly in R3 is this: 
You are encouraged to not program that way in R3. Converting strings 
to words is something you should do once, not all the time in tight 
loops. Your code will be much more efficient if you work in REBOL 
data rather than storing your code in strings and converting at runtime. 
Strings are for data, or script source, not for containing scripts 
at runtime. This is a good rule for all REBOL versions, but especially 
for R3 with its Unicode strings vs. shared UTF-8 words.


* I have recently refactored LOAD so that it is broken into smaller, 
more efficient functions. You might find that those functions would 
work better for you in lower-level code. But this was done to let 
us make LOAD *more* powerful, not less, so the same advice I gave 
above about not using LOAD in tight loops still applies. I don't 
yet know if the new LOAD is faster or slower, but it is safer and 
easier to understand and modify, and you can make your own LOAD replacement 
that calls the same low-level functions if you like. Plus, you get 
compressed scripts :)

Maxim, maps are meant to be used like objects, but with different 
tradeoffs. The evaluation that you show is not a bug, it is by design, 
and it works for functions stored in blocks as well.
>> a: reduce ['b func [] [3]]
== [b make function! [[][3]]]
>> a/b
== 3

Use get-paths if you don't want evaluation:
>> print mold :a/b
make function! [[][3]]

I like the fact that you are modularizing LOAD... I did try to modify 
it before and well... I thought you where brave of even getting it 
to work at that point  :-)

Carl requested the modularization. And I definitely wanted to do 
it because the whole module and script system didn't pass the hit-by-a-bus 
requirement.

anyways, we do have get paths now... so I guess I'll just shut up 
and stop stirring air  ;-)