AltME groups: search

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.

Is doc coming back?  He hasn't been here for over a month

I saw a video that Henrik linked to ...

The Amiga he received was a Sam440, delivered by Steve Solie from 
amigaworld.net, AFAIR.

crazy prices for a sam440 board

I'll have to do a few more bounties before I can justify getting 
a board ....

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 ....

with a few more network schemes I agree.

yes - simply put - releasing R3 should mean, that ppl can do at least 
the same work, as using R2, or we have got a regression ....

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?

but, IMO, parallel processing should be transparent - we should take 
a look at how F# exposes concurrent programming - really intuitive

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.

R3 handles events on a timer base. So there is at least a way to 
do cooperative multitasking.

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.

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.

BrianH, was there ever talk about a function that returns only duplicates 
in a series?

I remember there being such a discussion, but it never really went 
anywhere.

if I say "pretty please", can we have such a mezz? :-)

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.

These would make good library functions. Give me a moment.

Would it be alright to skip the /skip option? Then we can use a map! 
to do the work without too much overhead.

I'm fine with that, but it would perhaps lose a bit of consistency.

I'm not sure if I can make a decision here.

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?

One would think so .. can you even reload a module?

The answer is yes!  However I'm not sure this is a good idea...

remove/part find system/modules 'module 2
import 'module

system/modules is a block. New modules are just added to the beginning 
of the block. Old versions are not removed by the module system. 
Security issues might prevent them from being removed at all in the 
future - this is an unresolved issue.

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.

For now, a lot of the possible errors are just asserts.

The new code is specificly designed to be less confusing. The old 
code failed the hit-by-a-bus test.

Look in the !REBOL3 Modules group for details. I've already given 
a lot of status updates.

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).

only tried using a file!, though

please try a directory

The blog talks about a 104 version.  My last one is 100.x.x.x

The blog talks about a 104 version.  My last one is 100.x.x.x

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

Shad made a wrong guess

but maybe it will be a real GUI

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.

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 :-)

Tasking/IPC is the last missing stone before we can claim R3 being 
a beta
 - disagreed

There is no definition of what constitutes a R3 beta

...even without a definition

It's a plus for a lot of platforms to be able to build on a minimal 
base. For instance, I would have loved /Base on WinCE.

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".

its always been a thorn in the side of the language.  if you don't 
need multi-threading, then cool... but I've lost contracts just because 
of this.

this is not a discussion about to beta or not to beta.   if we go 
to beta ... yay.. then in 6 months- a year... a design change required 
by tasks, forces Carl to either do a half-assed solution or go back 
to breaking R3.  what's the point of even going to beta.

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.

adding support for libraries, that is effectively something that 
uses the core... not defines it.


adding a standard SQL connector in REBOL would be sweet, but it won't 
change the core... its using it.

We don't need a R3, that is in development mode until dawn before 
we can make use of it.

Hence, we are working on getting incremental steps done, that are 
useful. Maybe not for everyone but a lot can be done with R3 now.

I agree... its very nice already.  I will be looking into the A 105 
release next week.

I'm not afraid of it. I know that I take a high risk here to break 
some code.

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

for example, could I build a gob! which uses another rendering package?

ok I'll try to figure out the Architecture from the code (its a pretty 
big codebase... a bit daunting, I admit)

From Carl:

Adding /output is a many-days/weeks addition. 


The R2 CALL function required 5 programmers over several months... 
3 of which were even world-class programmers.

If we find a qualified person to port this code, we can invite them 
here, or on another world.  (Only 1 in perhaps 1000 programmers are 
skilled enough.)
 :-)

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.

ah, sorry ... a really old one :-)

my only gripe is that we can't use a digit as the first char... I'm 
wondering if there are other problems.

>> system/version
== 2.100.106.3.1

>> a: #1
== #1

>> any-word? a
== true

oh, cool .   so I guess the issue is that issues now clobber the 
word space.

is there a word count limit in R3?

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

Henrik put up a link to his newest build in REBOL3 GUI:
http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3

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

Should I expect something different?:

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
>> source show
show: make command! [[
    {Display or update a graphical object or block of them.}
    gob [gob! none!]
]]
>> source size-text
size-text: make command! [[
    {Returns the size of text rendered by a graphics object.}
    gob [gob!]
]]
>>

I was trying to make a build with r3-gui.r included, but when running 
the generation step of the build make-host-init.r outputs the error 
"Invalid tuple -- 2.147484e9x2.147484e9" when processing this file. 
Is there something wrong with this tuple?

Is there something wrong with this tuple?

 - sure, first of all, it is not a tuple, it is a pair, which your 
 version does not recognize

heh, of course it's not a tuple - my brain was trying to focus too 
hard on what was wrong with the pair - why wouldn't my bersion recognize 
it? Because make-host-init was done before the float pair support 
was added?

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

No, it doesn't need Henrik's view source which is a moving target

skimming... r3-gui.r3 requires A105. anything below will give a size-text 
error.

Carl, or anyone else who remembers - I don't recall what is holding 
things up in terms of making the source available so that people 
can try their hand at a client for R3 chat

Why do you need the Rebol source code to make a R3 chat?

just to see what the back end is doing - what API it exposes, etc. 
Of course you could find some of this out by sniffing, but why should 
this be needed. BTW, I'm talking about a client (say a web one) for 
the chat server that the built-in client connects to

>> demo
Fetching demo...

Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none
This R3 release does not provide a graphics system.
The demo cannot be shown.
>> do http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3
Script: "Untitled" Version: none Date: none
** access error: cannot open: %shape.r reason: none

>> system/version
== 2.100.107.4.2

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.

shoudn't resolve have a refinement called /bind  making it easier 
to rebind data to target context in a single pass?

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.

so for example, if an application halts due to an error... the stack 
is effectively empty, since its back to the command-line.  :-(

ex:  I added a voluntary 0 / 0 to generate an error.

liquid/add[3]/instigate() [
** Math error: attempt to divide by zero
** Where: / unless cleanup switch foreach either if insti
** Near: / 0 plug/dirty?: plug/valve/purify plug if all [
    plug/re...

>> stack 10
== none

this is a welcome change in R3   :-)

>> a: to-integer to-binary red
== 16711680

>> to-tuple to-binary a
== 0.0.0.0.0.255.0.0


as opposed to in R2

>> a: to-integer to-binary red
== 16711680
>> to-tuple to-binary a
== 49.54.55.49.49.54.56.48

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).

strange load behaviour.....   it doesn't load a file as rebol data... 
its only a string... I just had to do:

load load %datafile.r

just like if I was doing:

load read %datafile.r

it seems to be related to the extension....  only a file with .r 
as extension is loaded as data... this insn't very cool.

can anyone verify this claim before I post it to curecode!
should be run from where you have the r3 view tests installed.

;--------------------------------------------------------------------
rebol [
	title: "crash report for R3 - A107"
]

do %gfx-pre.r

; this works ok 

blk: load http://www.pointillistic.com/open-REBOL/moa/files/a107-draw-block-ok.r

;-------------
; same as above with A SINGLE circle added .
;
; crashes, with   "REBOL system error #1207:  assertion failed "


; adding a few items ALSO creates a windows READ memory exception.
;
; uncomment to provoke crash

;blk: load http://www.pointillistic.com/open-REBOL/moa/files/a107-draw-block-bad.r
;-------------

win: make gob! [size: 500x500]
box: make gob! [size: 500x500]

box/draw: to-draw blk [] ; crashes 


win: make gob! [text: "Basic DRAW test" offset: 200x20 size: 300x300]
append win box

win/text: none
win/color: red
init-view-system
view/options win [
	offset: 200x100
]

very strange... can you give me link to your compiled version?  I 
would do some tests... could be a compiler issue.  what are you using 
as compiler?

how can I get a specific version of gcc?  AFAIK mingw's online systems 
allow only an old 3.xxx version or the latest 4.5 which doesn't compile 
rebol at all or crashes it.

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.

TL;DR: You can't create error categories of error codes above 996, 
is there a reasoning for that?

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.

If Outlook as a COM interface, you can use that