• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

DocKimbel
2-Nov-2012
[3253x2]
Speaking about earning some money:
I'm very glad to announce that I've received the biggest amount of 
monthly donations in October: 997.65€ received (~$1277) from 8 donators. 
That not only easily covers my monthly bills, but also allows me 
to save some money for future trips to devcons. So thanks a lot to 
all donators!

A special huge thank to Bas de Lange for making a big donation!
Pekr
2-Nov-2012
[3255]
!!! Cool :-)
Kaj
2-Nov-2012
[3256x2]
I tried different versions of cURL on Windows 7, but read-we-page 
is still unable to reiolve the URL
cURL works from the prompt, so Windows is doing something awkward 
that keeps my Red/System program from working
DocKimbel
2-Nov-2012
[3258]
I'll have a look at it tonight.
Kaj
2-Nov-2012
[3259]
The other remaining issue is that play-SDL-WAV appears in the Windows 
7 mixer, but stays silent
Jerry
2-Nov-2012
[3260x2]
What's the difference between Sysmbol! and Word!
Symbol! in Red is like Issue! in R3, right?
BrianH
2-Nov-2012
[3262]
In R3, a symbol is the internal unique string that a word refers 
to. A word is a pointer to a symbol and another to its binding. Same 
in Red?
DocKimbel
2-Nov-2012
[3263x2]
Same in Red.
Jerry: symbol! datatype is not reachable for Red users, it's an internal 
feature. I might also add series! and context! datatypes, it will 
be for internal use only too. You can see the types hierarchy at 
page 22 of this presentation: 

http://static.red-lang.org/Red-SFD2011-45mn.pdf

(the types in italic are internal types, not accessible for Red programming).
BrianH
2-Nov-2012
[3265]
You don't have typesets?
DocKimbel
2-Nov-2012
[3266]
Not yet, but I will add them.
BrianH
2-Nov-2012
[3267]
That can deal with the series! type, unless you have an internal 
reason to have it be a real type.
DocKimbel
2-Nov-2012
[3268]
Also, the ipv6! type might not be derivated from binary! if it can 
fit in a value slot.
BrianH
2-Nov-2012
[3269]
I don't see how it could fit in a 128bit value slot, but maybe in 
a larger one.
DocKimbel
2-Nov-2012
[3270x2]
Internal reason: type inheritance mainly.
I don't remember how long was an IPv6 address?
BrianH
2-Nov-2012
[3272]
128bit.
DocKimbel
2-Nov-2012
[3273x2]
Can't fit a value slot, so it needs it's own buffer.
*its
BrianH
2-Nov-2012
[3275]
If you have support for unboxed intermediate values or unboxed series 
types (like vector) then you can make sure you can do IPv6 types 
that way too.
DocKimbel
2-Nov-2012
[3276]
What do you call "unboxed intermediate values"?
BrianH
2-Nov-2012
[3277x3]
Side effect of compilation. The compiled code retrieves a value from 
a value slot or other indirect type, manipulates the values in typed 
stack or register variables, then puts the results back in the value 
slot or wherever.
You'd likely need to use two 64bit registers unless you use SSA or 
something.
Sorry, SSE.
DocKimbel
2-Nov-2012
[3280]
Ok, I wasn't sure what you meant by "intermediate". Red compiler 
will heavily rely on unboxing for all the optimizations.
BrianH
2-Nov-2012
[3281]
Right, otherwise there's no point to going through the trouble of 
compiling (aside from the challenge) :)
Jerry
2-Nov-2012
[3282x3]
in R3, Date! is not scalar!. In Red, Date! is scalar!. Why?
Also, in R3, Issue! is any-word!, not any-string!. But in Red, Issue! 
is any-string!
Hope I can keep learning Red while your are developing it. So I can 
help in book writing or something like that in the future. :-)
BrianH
2-Nov-2012
[3285x2]
In R3, date! isn't in scalar! because scalars need to be able to 
support +, -, * and /, and two of those don't make sense for dates.
The issue! type was changed from a string-like type in R2 to a word-like 
type in R3, but the R3 behavior isn't completely final. It will continue 
to be a word-like type, but the syntax might get some tweaking and 
some string-like operations might be added back where possible, perhaps 
in a similar way to how tuples are series/like at times but actually 
immutable.
DocKimbel
2-Nov-2012
[3287]
Jerry: I haven't decided yet for issue! datatype. By default, I stick 
to R2 model. For scalar!, Red definition might differ a bit from 
R3 one, we'll adjust that if required when the work on date! will 
begin.
DocKimbel
4-Nov-2012
[3288]
I have pushed a commit yesterday night that reimplements almost fully 
namespaces support in Red/System. It is now cleaner, fixes a lot 
of issues and it is allows faster compilation of apps that heavily 
rely on namespaces like Red's runtime code. For example, the demo 
Red script now compiles 20% faster.


Please test well your current scripts to spot eventual regressions 
caused by this change.
PeterWood
4-Nov-2012
[3289]
james_nak: When you run the Red tests, their output is logged to 
Red/quick-test/quick-test.log. Would you mind taking a look to see 
if any error message was logged.
Kaj
4-Nov-2012
[3290]
I haven't seen any regressions yet in building the bindings with 
the new CONTEXT implementation
DocKimbel
4-Nov-2012
[3291]
Good! Thanks for reporting it.
Kaj
4-Nov-2012
[3292]
Oddly, the Windows (and MSDOS) builds are changed, but I can't see 
where that's coming from
DocKimbel
4-Nov-2012
[3293]
Changed how? Size or content?
Kaj
4-Nov-2012
[3294]
Content, I suppose. Probably not size, as Windows works with pages. 
I checked them in, so they can be retested
Jerry
5-Nov-2012
[3295]
I am studying Red/System. For me, it's good enough, so I am curious: 
What can C do and Res/System cannot do?
DocKimbel
5-Nov-2012
[3296x3]
From top of my head: C has unions and can pass struct by value. Both 
those concerns should be addressed in future Red/System versions.
s/concerns/features
Another missing feature in Red/System that C has: 64-bit integers.
Jerry
5-Nov-2012
[3299]
Yeah, I thought about the lack of union.
PeterWood
5-Nov-2012
[3300]
You can address bits in C but not the current version of Red/System
DocKimbel
5-Nov-2012
[3301]
Right, no bitfields in Red/System (yet).
Kaj
5-Nov-2012
[3302]
Stack allocation of local structs