AltME groups: search

That sounds good. I need to take some time tomorrow to think about 
all that and see if there's no drawback hiding somewhere.

Right. And language-specific and library-specific on any given platform. 
That is why it needs to have a good way to specify it.

For C and a given platform (and a given compiler, for some weird 
corner cases), default alignment/padding behaviour is specified.

Right. And since that changes from platform to platform and compiler 
to compiler we need a way to match those differences, with declarations 
or options or pragmas, same as the C compilers do.

Otherwise we can just drop the whole attempt at easier integration 
with C and go with a much more sensible storage layout dialect (think 
e.g. Erlang bitstrings).

Another important issue is that the defaults be settable on a per-platform 
or per-app basis, and that the behavior of Red/System is explicitly 
defined in a cross-platform way. We don't want to repeat the mistakes 
of C just because we're interfacing with C.

A lot of the stuff we have to integrate with will have C interfaces, 
but those interfaces will have struct layouts in them that were declared 
with precision for binary compatibility, using the pragmas and stuff 
that C was retrofitted with to allow such precision. We need those 
kinds of abilities from the beginning, or we'll have to retrofit 
it on later just like C did.

Plus, struct references will be used to convert data to and from 
binary data read from files and network protocols, and those also 
need precise definitions.

I'd use a different and far more powerful dialect for that.

But if you don't have a way to specify the padding and maybe alignment, 
you won't be able to interface with C code that sets that stuff too.

You are a little spoiled on Unix-like platforms, Andreas. On Windows 
there is no standard C compiler; there are a bunch of competing ones 
instead. Each has its own quirks and defaults. Since Red is not itself 
written in C, you can't just go with the quirks of the same compiler 
it is written in. And different libraries are compiled by different 
people with different compilers. If you want to interface with them, 
you have to be specific.

It's worse for me usually, since most of the libraries I need to 
interface with are written in languages other than C (C++, Delphi, 
.NET, Java), or have to match precise binary interoperability standards 
(COM, etc.). Simple C compatibility would not work for me at all, 
and this has also been the case with R2's library interface. Fortunately 
the database access has made my SDK license worth it :)

Thanks guys for the insights and propositions. I found it a bit difficult 
to follow in realtime, I'm not sure that AltME is the best tool for 
such conversations. Maybe we should give a try to the Red web forum 
next time: http://groups.google.com/group/red-lang?

Well, usually, you have more time to read and reply on a web forum 
before the post you're referring to, gets lost in the flow of new 
ones.

With mailing-lists, you can have a threaded view of conversations 
in your email client, so you can easily follow replies to differents 
posts. I usually have no issues following replies on AltME except 
when several users are talking together and posting replies fast, 
it becomes hard to follow in realtime.

I guess that in AltME, if we could have a way to "mark" the post 
we're replying to when required, and the ability to switch to a "threaded" 
view, that would help a lot. In such "threaded" view, related posts 
could be grouped together with a [+] button somewhere allowing to 
unfold it and see all the replies to a given post. If posting while 
a thread is unfolded, the post would be considered a reply without 
having to "mark" the post related to the reply.

move it to groups and make it visible to the outside world

If you need some external eyes to look at your code or test it (I 
can test on OS X), you can "gist" it  (https://gist.github.com/) 
and put the link here. I, Andreas, or someone else could have a look 
at it.

Doc, I will do some cleanup and put it there.

segfault is caused by kernel and bus error by memory

(using .r2 and .r3 extension would give proper code colorisation 
at github)

red-lang.org redirects to www.red-lang.org for me with both Safari 
and Firefox.

Doc said "I found it a bit difficult to follow in realtime, I'm not 
sure that AltME is the best tool for such conversations"... I must 
say that I have a problem to follow conversation on blog if it's 
in french only. And I always found it strange that someone writes 
comment under article written in english in a different language... 
usualy in french.

Sure, but that was Subversion just a few years ago, and it will be 
something else a few years from now

A online tool like Github is making contributions both easier to 
do and easier to integrate back in the main project.

I know, it's the existing community and infrastructure that's the 
issue

If AltME could have a pure web client (supporting search engines 
indexing), threaded conversations, an email bridge for reading and 
posting, and an open API, it would probably become the best solution 
for online communities (of developers or other kinds).

one of the main thing that makes  rebol a farce is  the object! concept... 
It's just a cosmetic issue to claim that rebol  can deal with object 
and so it is OO ... Ridiculous rebol's object! type is just a half 
assed C struct... You want people to take you serriously don't pretend 
doing things you don't and don't claim being things you don't because 
you labeled something to be like that. rebol object! have only attributes 
no methods no encapsulation, inherence is only from 1 source, no 
polymorphism, no abstraction

I guess you wanted to post that to ~Vent group and posted that here 
by mistake?

I wanted to post here anyway as the things goes usually with this 
community we will have a 6 month red is  everywhere thing and then 
noone will care anymore.

Are you aware that your post from 17:58 has nothing to do with Red? 
It's just off-topic. Btw, thank you for your very smart and constructive 
comment.

Dockimbel it has a related topic ... Don't do like rebol did ... 
Claming to do things you don't.... and the object! type and whole 
OO justification made by Carl to justify his choice of a half assed 
OO concept  is null ... And that's what I want to share with people 
in red ... you shouldn't even try to be parasiting rebol (create 
your motion around rebol lack of motion using communication tools 
that are seen by 10 guys that are fanatics of rebol and won't support 
red...). Set you own discussion tools create a communication branch 
aside and invite people here to join you without counting on them. 
And more importantly try to convince non reboler to join and help 
you. face it there is way more people outside rebol community than 
inside.

c-string! is confusing their is no String in C to start with ... 
maybe in C++  or in java but then they are objects with utility related 
methods and red don't have object like said brianH

shadwolf: If you don't like REBOL nor Red, I wonder why you're losing 
your time (and our time) by posting here? Didn't you announce that 
you were leaving the REBOL community a few weeks ago?

dockimbel I can't say I don't like Red I don't  saw it ... But the 
idea of harvesting the remains of rebol's corps bother me ...  You 
don't even have red done that you put it on the same tracks using 
the same talent less people... do whatever but don't cry at the end 
of the year when red will be used by noone and that the red community 
will be the very same as rebol community

and I propose manything  but you are too limited apparently to understand 
them first is if you do things do them the right way not the rebol's 
way. You should sever ties from rebol community since they are not 
able to drive their own projects  how could they drive Red.

and if I asked is because I rode the bunch of lame craps here and 
it's exactly the same amount of crap comming from the same people 
on any other topic here ...

Look into Red's page on github and count them.

i'm looking at the github i see dockimbel along every files and only 
Peterwoods for doc dir

and those people are the people from here ...

you are on rebol's track you already did a dead born clone of rebol 
and red is going the same path but with R-sharp at least there were 
4 people working for it no 1 with 2 bug trackers

and  red is looking that way ....

I've listed 4 peoples in the README file, but Brahim's and Arnaud's 
source code never made it in the repository (project stopped before), 
Volker's contribution is a 10-lines C function. That's hardly a "4 
people working for it". I have written 99,99% of the released source 
code.

Anyway, aside from wasting time, bandwidth and trying to spill your 
negative emotions to all peoples here, do you have something useful 
to say? If not, I'll just go resume my work.

And what good work you've been doing! :)

DockImbel appart this is yet another joke and you prove it today 
? nope ...

for more information about red referes there http://www.red-lang.org/
Instead of coliding with me dockimbel you could had just said that 
and nothing else it was plenty enough...

so red is compiled but then it's systeme dependant and we can't test 
small chunks of code like in R2 consol in my opinion one of the strong 
point of rebol was this ability to open it's consol test an epurated 
bunch of code and then once working enhance it on our script file. 
I would like red somehow to get that  ability maybe it will be possible 
in the IDE or as a side stuff. For me the 2 best points of rebol 
were reflexivity code <--> data code = data data = code and parse. 
Even if I didn't fully understand parse I made a great use in my 
productions in rebol script VID oriented of the reflexivity code 
<---> data. All the other arguments of rebol are not really interresting 
since they are double sided and so not objective and so just a matter 
of mood and point of view.

I.E: the rebol's VM size is small, that's an adventage if I work 
on a computer with 1.44Mo flopydisk as main support, it's just stupid 
if I have 1Tera e sata hard drive. Or rebol vm runs everywhere your 
script the same, you take area-tc and surprise it doesn't work on 
windows seven on linux and macOS X.  Or it's easy to do networking 
with rebol. If you do TCP or UDP yes if you do something else you 
are unable to proceed ... see that's always double side half truth 
in rebol and that's really what I don't want to see in Red this is 
not a big contribution but it's important enough for me to be said.

this seems fun p:   &[integer! 4000000h]   but then how do you know 
this adress is free and that it will hold the data you have in mind 
? will you be able then to make this countainer changing from integer! 
to c-string! ?

Those & things have all the advantages and disadvantages of pointers. 
You don't know whether there is anything there unless you put something 
there, same as C.

A related question: What if I create a function, the multiply a local 
variable of type integer with some global variable, and I run that 
function in a context, where the global variable is a string? Are 
the datatypes being checked at runtime?

Currently only the Red/System dialect is specified and implemented, 
so I'm not sure if the context of your questions is Red or Red/System.

What if I create a function, the multiply a local variable of type 
integer with some global variable, and I run that function in a context, 
where the global variable is a string?
  The compiler will catch the type mistmatch at compile-time.

Are the datatypes being checked at runtime?

 Not in Red/System. Partial runtime type checking could be added at 
 Red level.

The exact frontier between REBOL features that will be supported 
in Red, and the ones left aside is not yet accurately defined. In 
fact, it is possible to support almost every feature of REBOL, but 
the performance (and maybe memory footprint) to pay might be too 
high. For example, supporting dynamic scoping and BIND-ing at runtime 
is possible in Red, but the speed impact would be so high, that the 
compiled version wouldn't run much faster than the interpreted one.

As I don't plan to have different semantics for the Red code statically 
compiled and the code JIT-compiled, the supported Red semantics would 
need to compilable fast enough. That will be one of the main constraints 
that will finally decide what REBOL features can or cannot be supported.

for the more obscure types and also for user-creatable types.... 
basically they are classes which have a specific and non-extensible 
set of methods with an arbitrary content which is used by the interpreter 
directly.

when the compiler uses them, it uses the code in the 'methods' instead 
of its own to assign and retrieve data.

I do not plan to support such feature directly. But the code is open, 
and I will add a plugin API to the Red compiler to allow it to be 
extended by third-party libraries. You'll be able to implement classes 
with accessors if you need them.

It is intended, I'm updating the HTML docs only then a revision is 
completed, which is not yet the case with "draft 3". It should be 
finished in a few hours and the HTML docs updated by tonight.

I suppose that means you should fork the repository, develop the 
documentation in the branch, and then merge it back :-)

After re-reading the new specs draft, I noticed a few errors in the 
pointer! examples. Also, I think that having struct! passed as value 
by default was a bad move, it makes the "passed by reference" case 
too verbose (requires to declare a pointer! [struct! ...] and a get-word! 
syntax). I think that I'll revert default struct to be passed "by 
reference" and find a special syntax for the extremely rare cases 
when a struct needs to be passed by value. I can't remember any OS 
API nor mainstream C lib that require passing struct by value (anyone?).

I've made some drastical changes on pointer! datatype, to clean up 
the mess it brought (syntax ambiguity and verbosity, semantic clashes 
with other implicit pointers like c-string! and struct!). The new 
specs draft simplifies all that. I'll push it online in a hour.

I forgot that such feature existed in AltME (as for Calendar and 
File Sharing).

So variable names starting with a-f, consisting of a-f and 0-9 and 
ending on -h isn't possible.

No, and I should add it the variable syntax section in the draft.

Who started boron and red?

padding with zeros and uppercase only sounds good.

Peter was asking a question about c-string! syntax. There is no need 
to have separate syntax for c-string! and string!. Red/System should 
only have c-string! literals; the string! type is likely to be *implemented* 
in Red/System, so the type name would only be needed to refer to 
values that Red/System is constructing or converting to or from. 
Red itself shouldn't have a c-string! type because it's unsafe, same 
as the pointer! type. So you can use the same syntax for both string 
types: In Red, they would be string! literals, in Red/System, c-string! 
literals.

Nicolas: "Why is it more popular than boron? Did the boron guy start 
red?"

A few apparent reasons:
- Red is new (shiny!).

- Red is compiled, which is a new challenge for us. Boron is interpreted, 
like REBOL.

- Red is BSD licensed; Boron is LGPL licensed. Most of the REBOL 
community is not very (L)GPL-friendly for various reasons, such as 
license incompatibility with REBOL.

- Red being compiled and BSD means that it doesn't directly compete 
with REBOL, and is considered to be complementary. We might even 
be able to get them to work together directly without causing license 
problems. This means that more people who contribute to REBOL itself 
can contribute to Red as well, which means that there are more qualified 
contributors available early on.

- Doc made Red, and we like Doc, and he is here. Karl Robillard is 
not here, afaik (I'm sure we'd like him if given the chance).

and are they discouraged to use GPL?

yeah... any invention eventually needs to be leveraged... that's 
ok.    and most high-profile research is funded by companies nowadays... 
I'm pretty sure its like that in all universities in the US.

The big ones, yes. The others don't do a lot of research. There are 
exceptions though; my old professor contributed to Pizza, which led 
to generics in Java 6, and indirectly in C# 2.

a lot of companies go to universities for some specific problems. 
 they fund a specific project form a team and a professor and team 
has work for 2-3 years.  sometimes it goes through the school, sometimes 
it almost like "renting" the professor for cheap.

Humm, looking at it a bit closer, it is not totally equivalent: the 
* and / operators will generate shifts only if the right argument 
is a literal integer. So: 
    a: 4
    123 * b
won't generate a shift.

So, I guess the conclusion would be: it is worth adding them. :-)

Will  << and >> be needed in order to build the first version of 
Red?

yes and maybe light enlightment of design (ie metacode is created 
by compiler or linker?)

and what linker cares about, glues together multiple compiled source 
files?

Compiled source files are glued together by the compiler itself. 
The linker currently simply generates the right binary from compiled 
code, global data and external libs imports. The linker will be later 
extended to be able als to statically link external libraries.

Emitter module purpose is to isolate as much as possible target-specific 
code from the compiler. So, it provides target-independent helper 
functions to the compiler and for target-specific code, it loads 
one from  %targets/ folder.

I just visited the Haiku OS website, and I can see, that it was accepted 
for the Google summer of code 2011. Maybe once Red becomes an alpha, 
we could apply too? Let's say for 2012 :-)

No, you would qualify for the mentor part. So you'd have to find 
students willing to write open source Red code, and then you have 
to mentor them

It's very hard to get into SoC, beginning with the rush to register, 
and if you don't have the organisation to conduct the mentoring, 
or your project is too eccentric for students to get into quickly, 
it's fairly pointless

(and google also gets to notice you a little)

Questions about the declarations.  

1-  why are you using this syntax for *all* declarations? : 
word: [datatype value] 

ex:
my-val: [integer! 20]

woudn't just this do ?:
my-val: integer! 20

I find its a hell of a lot easier to read,


and when you add type detection, its back to 

my-val: 20   


meaning that the integer! word really is just a typecast operation 
here.

since you are compiling and pre-filtering the source code, the integer! 
word really is contextual,  what it means is inherently bound to 
where its found.   so I see no issue with this use syntax.

anyone care to debunk me?  am I missing something?

Doc, I have to say, the red docs are getting really nice.


its clear now, and I was talking nonsense... I should have gone over 
them... will make sure to visit each time. they've significantly 
updated since last I visited.

I was just taking a little break from all of the cheyenne dev.

Yes, I saw that and want to test it, but I'm very busy. Maybe I'll 
get to it tomorrow

Kaj :That's cheating, that was ported from Boron ;-)


Not true. That was my initial intention but simple-test was felt 
to be too heavy for Red/System so I built a lighter one.

By the way, the boron framework was ported from REBOL ...
.... and back again :-)

(getting off topic) The main problem was that GPL2 code *written* 
in Java was illegal to *run on* proprietary JVMs and link to even 
the bundled Java libraries. The same goes for GPL2 code written in 
REBOL. LGPL2 is a little more legal for running on proprietary languages, 
barely.

There were and are a lot of popular GPL2 apps written in Java, but 
none of them are legal to run (ish, depending on distribution).

I notice you write *GPL, and while I could agree with stating that 
GPL is a one-way street, LGPL is not

Porting code in Boron itself - rather than code that was just written 
in Boron - to Red itself without relicensing it would make Red mixed-license, 
BSD and LGPL. Going the other way, porting code in the Red project 
to the Boron project wouldn't affect the license of Boron; it could 
stay LGPL only.

And the original authors of any LGPL code in Boron could relicense 
it as BSD if they want it added to Red. No problem, if the author 
agrees to it.

I believe that it is most unlikely that any code will be ported from 
boron to Red because Red will first be written in REBOL and eventually 
in Red whilst boron is written in C.

Brian, it's FUD because you are changing the topic. You're jumping 
from the effect of the licence of platforms on application code to 
the ability to mix and match platform code

None of this affects user code written in either language though.

When I realized that Peter was talking about user code, not code 
from Boron itself, I said "Cool." and then just clarified something 
based on what Peter said next. It was not steering the conversation, 
though I apologize if it gave that impression. License compatibility 
for contributions is a real problem (which is why I reacted to the 
FUD remark), but it is a problem with limited scope, and is solveable 
even within that scope. My response to that FUD remark gives the 
overview of the limited scope of the problem, and how to get around 
it (relicensing with author permission). No unsolveable problems.

Peter changed the topic when he said "I don't believe it is GPL because 
of that just as all Java code is not GPL because Java is GPL.", and 
that is what needed clarification. Unfortunately, I couldn't move 
that message to the Licensing group, or edit my responses to be more 
clear (stupid AltME).

These two are different, pointer! is used to refer to the datatype 
and have to be used in function's spec blocks. Pointer (without !) 
is a keyword (like struct) used to represent a literal pointer value.

As was the ticket. Remember that in Red proper, AS should do conversions, 
not casting, for safety. Given all this typecasting, it is looking 
more and more like Red proper should have the handle! type instead 
of pointers, where a handle! would be a pointer-like thing with no 
dereferencing, arithmetic, or value setting or getting in Red itself. 
Then let Red/System cast the handle! to whatever pointer type it 
needs to.