World: r3wp

Cyphre, thanks for the FreeType code. It's a while ago that I looked 
at the src/os/ files, but they seemed fairly large and complicated. 
I won't have time to start that project until at least after ReBorCon

BrianH: Find the 10th item would mean chaining 10 FINDs.

find-nth: func [series value n] [
    loop n [unless series: find series value [return none]]
    series
]

I like Gabriele's solution, especially with FIND being an action.

that's ok

Isn't this inconsistent?

>> to-word "d"
== d

>> to-word #"d"
** Script error: expected word! not char!
** Where: to to-word
** Near: to word! :value

Yup. TO doesn't support all conversions, but from chars makes sense 
to support.

Ok, what to do? Create a CC ticket?

Yup. Make it a Wish, for TO conversions from char! to word!.

I need a login...

Submited

Seems the Color Nook can run Android 2.2 ( aka Honeycomb ).  And 
R3 is now running on Arm.  What's to do to get it running on Android?

2.2 is froyo, honeycomb will be 3.0

ok, still there are going to be a lot of cheap Android tablets out 
there...

pity we can't have Rebol OS running on this cheap hardware

Port the host-kit.

See the Android group here for details.

Unless it is official, it should be regarded being not official. 
Carl still needs to start regular communication at least on blogs, 
or R3 Chat, to his devs. Putting it other way around - where can 
one download r3.dll for Android?

A Linux shared lib would do. But no download has been announced, 
even privately.

Has anyone considered doing an extension for LibHaru? This could 
be useful.

http://libharu.sourceforge.net/

there's already a rebol library for this

rebol2

Found it... but it would be nice with an R3 version.

RebHaru looks fair, but it could use a dialect

See PDF group on RebHaru

Carl just made an internal test release of A111.

Carl has a post to his rebol.net  "R3 FrontLine"  blog about looking 
for GitHub code submissions ... says only sees those of Oldes ... 
no comments to that post ...

-> blog chat

It seems that copy/deep doesn't work on map! Is it known problem?

I'm experimenting to determine the exact syntax of words in R3, and 
see whether there are any undiscovered bugs. Just sticking to ASCII 
for now - due to http://issue.cc/r3/1230- but things look promising 
so far. I'll convert the results to PARSE rules.

Found two bugs so far and one undocumented issue (or possible bug).

And an expansion of another bug (http://issue.cc/r3/1478).

Put the parse rules in a comment here: http://issue.cc/r3/1302

Nice work

I'm hoping to get a grammar for the whole language. We would then 
be able to convert it to various syntax highlighting engines, analysis 
tools, whatever. Figuring out the R2 syntax will take some different 
tricks though, as it doesn't have TRANSCODE and proper binary handling. 
I eventually hope to be able to write a TRANSCODE for R3 and R2 in 
REBOL source form, for documentation and analysis purposes.

There is a bug in R3, which will be very difficult to find... I was 
parsing very large XML files and have got invalid chars in the result. 
I cannot reproduce it unfortunatelly.

That sounds both very worrying and a challenge - how big were the 
XML files? Were they utf-8 encoded? Did you verify the utf-8 encoding 
in the XML or could it have contained invalid utf-8 sequences?

If you can give a few hints, I'll see if I can reproduce the bug.

For that matter, were you parsing them as string or binary data? 
If binary, were you using string constants?

It will not be easy as I do other operations as well.. like image 
resizing using extensions etc.. but it's strange... parsing as string.

Might be memory corruption then.

hm.. I can reproduce it... and it must be GC related, because when 
I set recycle/off, the result is correct

But it's possible, that it's my extension which is the reason.. I 
guess. How much safe is creation binaries from C level and passing 
them to REBOL?

Hm... now I 've got System Error #1301: invalid datatype 176

with recycle/off it's fine... it must be related to my extensions.

sounds like a memory corruption problem

Creating and returning binaries is supposed to be safe if you do 
it in one go

Is there any place in your extension where you create more than one 
series in one command?

Is there any place in your extension where series are passed between 
commands and are supposed to survive between calls?

The act of processing large data may very well trigger such a vulnerability, 
because otherwise no garbage collection would happen to be done