AltME groups: search

Try with following C executable:  http://static.red-lang.org/tmp/loadlib.exe
(or .zip if you have issue downloading the exe).


Put it in the same folder as temp.dll and run it from DOS shell, 
you should have something like: 

C:\Dev\Red\red-system\builds>loadlib
error: 0
hModule: 268435456				;-- library handler
error: 0
&f1: 10001a85				;-- f1 function address
124						;-- f1(123)
error: 0

Petr, can you please try loading the DLL I provided, so we're sure 
it's just som eproblem with my setup?

Try to watch what happens when loading the dll using Process Monitor 
and File Monitor from System Internals.

You are trying with Rebol/Core I think. it doesn't support library. 
Try with View instead.

I'll try with view ...

I might try to compile the library myself. How do I get different 
branch onto my PC?

Gregg: could you try to load this DLL using R2: http://box.lebeda.ws/~rebolek/temp.dll

lib: load/library %temp.dll
f1: make routine! [a [integer!] return: [integer!]] lib "f1"

My virtual XP machine is running I think Belgian localistation (turned 
off, but the base system is localised). W7 host is Czech localisation. 
I should try this with original US version.

MagnussunC: did you try to call the function::

>>f1 123

Rebolek and Pekr: I just fixed a regression in PE header, can you 
try it with this new revision?

Pekr: maybe you should try with this client: http://windows.github.com

So far, I suppose that the issue is caused by either:
- lack of relocation ability from the DLL (my #1 suspect)

- compatibility issue(s) with some system DLL (msvcrt.dll most probably)
- another unknown reason

I'll try to add relocation data to the DLL tonight.

Or try the full path to the DLL

I try to keep with the console Git to practice it properly, but it 
may not be easy under Windows. I don't know.

Petr - for a git GUI you might want to try SmartGit - free for non 
commercial use and, IMO, the best GUI. Also, it's available for all 
platforms. I use this, tortoise and the command-line, depending on 
the context

Will try that. I though I will have to do something on the github 
page. I thought it is "watch" which is needed, but it was not it. 
Clone in windows - what a name ;-)

Pekr and Rebolek: could you try to use ProcessMonitor (PM) to see 
if we can get a clue about what is blocking the DLL loading from 
R2?


1) Download it from: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
2) Run it

3) Open a REBOL console and CD to the folder where the DLL is located

4) In PM, drag'n drop the "target" icon to the REBOL console window
5) Type in console: lib: load/library %temp.dll

6) Scroll down in the PM window to look for rebol.exe process entries, 
look for failure reports in Result and Detail columns...

Pekr & Rebolek: can you give it a new try with latest commit (it 
adds relocation support to DLLs).

Try now:

foo: make routine! [a [integer!] return: [integer!]] lib "foo"
foo 123

I'm not sure it's useful to repeat this, because people seem to wipe 
their memory and start over the discussion, but:

- Red's roadmap includes binding to native GUIs. That means there's 
supposed to appear a binding for every platform Red is ported to. 
The intent is to try to create one dialect that would be able to 
drive all these native bindings. This would be a common denominator 
dialect.

- Some of those GUIs are actually cross-platform, such as GTK and 
Enlightenment. so those can figure as a cross-platform GUI. They 
could offer more functionality than the common denominator dialect 
but still be cross-platform.

No easy way AFAICT, even if the big picture is there, you need to 
think and take decisions for a lot of details every day, even if 
you try to isolate parts, you always end up with some conflicts to 
solve both at the design and implementation levels.

quick-test has been broken by one of the last 13 commits in branch 
v0.3.0. I'll try to sort it out over the weekend.

Try it the other way around ;-)

Nick: I'll try to do that.

Syscalls: given how much a programming language has to call OS services, 
I don't see why we shouldn't try to avoid an unnecessary layer. But 
I'm pragmatic, if we get more troubles than benefits, we'll adopt 
a more classical approach.

Please try again, pushed a fix a few seconds ago.

just one link - to the github red site ... then user should orientiate 
himself there ... nowadays visiting Red-lang.org does not suggest 
clearly, where one could get Red to give it a try ....

Alternatively, you can try to find a good existing open-source SSH/SSL 
lib that is BSD-compatible, so far, I haven't found  any. All the 
robust open source ones that I could found are under GPL.

Pekr maybe try this instead of with 1 2 3 4 5 
>> GET_BUFFER: [a b c d e]
== [a b c d e]
>> data: 4
== 4
>> GET_BUFFER(data)
== 4
>> GET_BUFFER/:data  
== d
>> GET_BUFFER/(data)
== d

Who implemented Try REBOL? Was it Kaj?

This is to try more Red beyond the things that are save to allow 
on a webserver/browser.

Jerry: My Windows doesn't support CJK, I'm not sure my Linux VM supports 
those characters too...will try it.

Pekr: try typing your Czech characters in Notepad (it has excellent 
Unicode support).

Pekr: try to set the "encoding" field to UTF-8 in the saving panel 
(Save as...).

So, give me an email, I will send the exact script to you for you 
to try ....

partially fixed, but my suspicion is, there might be other related 
problems. Will explain - I replaced "Dobry den" (good day) with "Vitej" 
(Welcome), with the comma above "i" char. Or try with just ordinary 
"i". Simply put - insert following line after the Czech HelloWorld:

print "Vitej svete" 

here it prints onle "Vitej sv"

Now off to try what happens with a Latin1 environment, but I guess 
it won't work :)

Brian: that last shortest path might be the first thing to try.

Hi guys - I am trying out Red/System and all seems very good until 
I try out Kaj's fibonacci and mandelbrot functions. I downloaded 
the c-library -sorted the paths and locations and tested the library 
on simple things and all compiles well. When I try to compile fib 
and mandel I get the following compilation error:

Ken: thanks for giving it a try. We might have left these two scripts 
lagging behind. Anyway, you'll have that fixed during the day (the 
good side of having a fast pace). ;-)

I will have a look into using Fossil and try again - it may be that 
the examples I have obtained are out of sync with the examples obtained 
through fossil - once I have figured it out I will try again and 
let you know my results -thanks for your help

Possibly, but I did go through all the #includes and made sure the 
c-library and common.reds was accessible and working, but like I 
said, I will try using Fossil and see what happens that way

ok - I will download v0.3.0 and try it on that too

My goal with the bootstrapped current version was to try some experiments, 
as all the current REBOL code will be trashed at the rewrite in Red 
stage. I wanted to see how far I could get with very simple design, 
so I can test how REBOL features can help or get in the way for writing 
complete compilers.

I could have gone by the (Dragon) book and done it in classic way, 
but that would have been a shame IMHO, to not try new approaches 
with a language like REBOL.

Depend on what you mean by "debug version" and what debugging tools 
you're thinking about. My plan for Red is to deeply integrate it 
with the IDE, so that you'll be able to have advanced debugging capabilities, 
like step-by-step debugging. Such feature could maybe also be ported 
to the console version, so you'll be able to use it even without 
the IDE installed.


Also, I have thought the Red execution architecture to be as reflective 
as possible in order to try to support memory image loading/saving 
and stopping/resuming (think Smalltalk). It's very tricky (not sure 
we'll have it in the end), but if we can achieve it, you'll be able 
to get a snapshot of a running Red program on file, transfer it and 
resume it somewhere else....ideal for reproducing exact bugs occuring 
conditions. EDIT: the right expression for that is "Image-based persistence".


In the meantime, we already have some "debug mode": -d switch for 
Red and -g switch for Red/System (we'll probably adopt -d for both, 
-g will be reserved for gdb support). It's mainly intended for internal 
usage for now, the Red/System one can be useful to locate runtime 
errors in source code (usable, but still needs some fixes though).

I'll try to fix it in boot config tomorrow.

I will try to fix those bindings issues on ARM once I release v0.3.0 
in a few days.

I will try that, I once did a pull request but it pulling doesn't 
make sense in my mind. I think it means the Github must be pulling. 
I will try again (with possible other improvements. If I am not succesful, 
I will put a file with my improvements up somewhere. Now to work 
(my job waits)

Agreed did one today but it was for git not for github. As github 
doesn't support OSX10.5 with her github for mac program I am temp 
stuck. maybe a REBOL script can take over the git commandlines for 
me. I go and try that to take me over the githurdle.

I know the french guy who used OpenCL to automatically parallelize 
some iterators for Scala, so it's definitely something I want to 
try for Red:
 
http://code.google.com/p/scalacl/

It seems turning off the multiple screens feature might fix it. I'll 
try tomorrow on the RPi localy (not through VNC).

Let's try to please Raspbian guys then with some cool Red features....but 
will need Red to be self-hosted first anyway, else we're limited 
to cross-compilation only.

rsc: context

 does contain "fail-try "Driver" [main]" that looks like a starting 
 point but it is within the context. So in my mind that does not get 
 triggered.

Also, when you try to build an operating system with Red, you'd get 
into GPL 2 territory in kernel space, and you'd have a problem with 
the many GPL 2 drivers. The media codecs and some networking protocols 
mirror that situation in user space

We have new Samsung 64bit Win8 machine in the office, I might try 
next week to run some tests there too ...

The host name resolving is the same problem I had with cURL. Now 
that I know it's on other Windows', too, I'll try more libcurl binaries

The %run-all.r script in root folder runs all the Red + Red/System 
unit tests. It does use CALL command which might need some permission 
under Win8? (just raw guessing, haven't tried Win8 yet). Can you 
try to run it using Admin priliveges?

Doc, I'll try that.

Thanks for the suggestion about until. Will try it.

Pekr: I try to use each channel for what it is worth for. :-)

If you realize that indices are one degree vectors.   A lot of this 
discussion becomes moot.   vectors of length 0 are considered impossible 
when considering only natural numbers (due to 0 divide).  This is 
why I consider R2's handling of indices proper.   


As such, any series "position" is not AT a value it is LOOKING AT 
a value (oriented in positive direction, starting at a point in space 
which is "0").   like extending your arm to grasp the nth thing in 
front of you.  


Tail are 0 length vectors (thus mathematically imposible), when we 
are beyond  the last item edge we are at the edge of space.   you 
cannot "take" the tail item, there is nothin in front of you, just 
as you cannot "take" the 0th item, there is no such thing, 0 is the 
origin of the vector).


when we consider series indices to be vectors, we see the natural 
relationship which Ladislav pointed with SKIP and other methods.


with vectors, things like COPY/PART make sense in the negative direction, 
just as well as in the positive direction.



In R3, this was changed to indices being OVER a value , with the 
first item requiring you to look down and then away for other values. 
 The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.


R3's series changes seem like a kludge work-around to map non-vectorial 
infinite integer space to a bounded vectorial space. sacrificing 
model integrity in the process (while trying to ease its mathematical 
properties).  R3's series *may* be "easier to count in a loop"  but 
the values being used make no sense.   counting backwards requires 
us to manipulate the indice for it to "make sense", whereas before, 
counting backwards was the same as counting forward.  we where just 
LOOKING in the opposite direction (the vector's orientation is inversed).

The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.

 - it may not be a "weird inconsistency", but it is almost imposible 
 to describe to a newbie in a reasonable way

Yes, but don't try to generalise from your brain to "most" or "new" 
users.

I know, but I must try to put myself in future Red users shoes to 
be able to make decisions.

I think it's more common to rewrite the code to something different, 
where possible, than to try and workaround the 0 gap.

Note that with R3-style bounds checking, the none value is considered 
to be roughly the same as a hole in the data. PICK past either end 
returns none. That means that PICK 0 returning none is basically 
a statement that there is a hole in the middle of the series that 
is just before the current position, and moves along as the series 
position moves along. Now, try to come up with a way to explain to 
newbies that this phantom hole in a series makes sense, or is a good 
idea.

Now, try to come up with a way to explain to newbies that this phantom 
hole in a series makes sense, or is a good idea.

 - yes, a good illustration from a beginner/documentation/education 
 POV. Also, what is exactly as bad even for experienced users is that 
 it disrespects arithmetic making simple index arithmetic (ADD INDEX 
 OFFSET) not usable.

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

Ladislav, don't quibble about "return" vs. "trigger"; you don't know 
yet how errors will be implemented in Red. In R3, for instance, errors 
are triggered by being returned internally. Try to keep the arguments 
on topic :)

(Sorry Doc about the off-topic stuff) And open-source forks that 
try to alter R3 to make ALIAS possible again will thus be that much 
less stable ond secure, so it will be an argument against their use. 
ALIAS is hostile to the R3 system model, and everything it might 
be a good idea to use ALIAS to do in R2 can be better done with other 
methods in R3.

I will happily allow people to use ALIAS on my Try REBOL server, 
just like I'm allowing most other REBOL features, because the server 
operating system is the party that establishes safe boundaries

You are welcome to try our server to see if you can break it with 
ALIAS

I have to wait to start programming my Raspberry Pi until I actually 
get it from Sinterklaas. After that I can try to test Red on it. 
I watched your presentation on programming in Red on the Raspberry 
Pi. No Syllable yet? WHat Linux did you use on the Rasp again Kaj?

I am trying to write a test red-system program but it is a pain:

I write it in my editor, then open a Rebol console and do change-dir... 
do/args ... then:

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. Which is the right method?

I've added binaries for all systems to my test repository, so you 
can now easily try the emulator if you have some ROM from the golden 
days:

So you can now try it immediately. Currently only for Windows, so 
it's in MSDOS\Red\console.exe

Let's try again: "Per the FSF, a program needs to be GPL'd if it 
calls interpreted libraries that come with GPL'd interpreter."

I hope I was clear enough. However, I may try to make my thoughts 
more precise. The script:

DO %my-script.r


is not "linked" with the definition of DO in any way at all. Only 
the interpreter "knows" the 'DO variable and does something meaningful 
with the code.

Very cool Etsy addition Nick. I agree that this will in the very 
least cause some curiosity about Rebol. And once you try it...

Henrik: I'm installing an XP SP3 image to try to reproduce your issue.

Arnold, please try to give a description of what works and what doesn't. 
But only after installing the relevant libraries

Here's a workaround you could try:

Doc, I would say that you should be one of the masters even if you 
don't have the time in the way of reviewing or coding if only to 
try to help steer R3 future development to be relatively in sync 
with Red's.

Ladislav - in 2004, when R# was slowly taking off, Carl published 
a blog article or announcement, describing R2 plugin feature. The 
supposed release was "imminent". Prior to that, Carl even contacted 
Doc to eventually stop working on R#, or so I remember. Of course, 
the announcement was just to distract ppl from alternative, keeping 
them interested in REBOL. 


Later on, I several times rightly identified some blog-post, whose 
purpose was nothing more, than to buy some time for RT, where in 
fact promissed things were not delivered. 


So - of course it is just my speculation, but with the history of 
R3 development I find it really curious to try to hype users to believe, 
that port to ARM could happen in 5 minutes, when RT was not able 
to deliver it is 5-6 years of R3 existence? And if so, it sounds 
a bit unfair to me ...


Simply put - wish Red, R3, World, whatever clone a success. It is 
just that what I would like to see is - a realistic estimates on 
any side ....

Arnold, just FYI, I'm tinkering with your redcompiler script, and 
will send you my version soon. When I started with REBOL, many people 
were kind enough to pass on suggestions, to make my code more REBOLish, 
so I try to do the same from time to time. It's not a critique of 
your code, just ideas you can accept or reject.

I pushed Facebook Rebol group  from 100 to 263 users now, but people 
is loosing interest in Rebol, I write the Rebol blog quite every 
day; and I'll dedicate my time also to Rebol Bazaar. I don't know 
why Rebol software is orphan and I don't care. I'll try to rise again 
it in the Olympus of best software (since nobody else do it), if 
you are with me you are welcome. I have no enemies, just friends.

I have the same problems with XP.
The exe does nothing but the url line.

If I try to do or read  the .red from the console-pro, the console 
window closes.

With the latest Android version it is nice to try type: HELP in the 
chat input prompt to see the BROWSE works nicely ;)

I'd urge you to just download it and try it. If you love Rebol, I 
guarantee you'll love Algodoo.

Anyhow, it's one possibility that I'll try to move along.

My objective is to move forward and spend as little effort as possible 
to be able to fight another day. So I must try to ignore the legacy 
languages as much as possible

Thanks, I'll try

I try to keep my build procedures as minumal as possible

sure, I'm hoping you don't need to - did you try and it asked for 
creds?

I can try again with a disk that is not pre-allocated

you should try the regular download - the other one requires more 
BS

if you want, np - I can try google drive, though

Adrian, I could try that with your OVF: use the configuration and 
replace the VMDK using QEmu. Could you upload it somewhere simple 
without the VMDK in it?

It's likely that people actually use or at least try the VM and live 
CD. The installer is downloaded about equally often as the live CD, 
and there it's doubtful that many of them lead to used installations