World: r3wp

SGUI ?

S for ?

oh !

Steeve ....

I guess it should be GUIdS since the noun follows in french

not bad :-)

GUIDuS

I found GuiMove but it''s already taken

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

hmm... tasty

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"

feel free to optimize

Why is this R3?

works in R2 as well. feel free to add it to R2/Forward.

What's the setting?

what setting?

what input is causing you to create this output?

Are you creating sentences?

blocks of strings, usually created for dialogs or other human readable 
output

I'd think that it is just something that you do :)

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.

Could someone please add an A105 version to R3 Curecode? Thanks!

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

Thanks, Brian.

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

(with both "the last" as well as "missing")

these are just opinions

There is no definition of what constitutes a R3 beta

Nevertheless, I do not doubt Pekr will be proven wrong.

...even without a definition

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.

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.

Everyone has different needs. I defined "my" needs for R3 beta in 
related document (wiki). The only thing I meant is, that I regard 
tasking/ipc being last "big" missing component. I have no problem 
being corrected or proven wrong ...

Is it that hard for you to realize, that your needs do not define 
what is R3 beta?

in must act on pekr's defence here.    his is just summarizing years 
of user expectations.

part of why pekr keeps insisting is that if you just look at the 
many changes the Extension/host kit has undergone since its first 
release, it can be expected that tasks will have as much side-effects 
in its own way.

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

I am talking about 15 years of use of REBOL by the whole community.

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.

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

Lad... why are you irritated about the need to address the task! 
issue?

do you think labeling "beta" on REBOL will change something?

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.