AltME groups: search

in that doc, it's not describing the stack for main() but the stack 
layout as setup for the entry point ("_start")

The documentation seems to describe that when you write a floating 
point constant, it will be a float32! if it fits. However, it turns 
out that it is interpreted as float64!

I've added some floating point convenience wrappers matching the 
other data types

Once the Red memory manager is available it may well be possible 
to use it to allocate struct! in a function but then there is the 
problem of how to release the memory later.


From a memory mangement point of view, it seems easiest not to allocate 
variables inside functions to be returned to the calling program/function.

There's a lot of variation in the results for such a long loop, so 
it does point to timer instability

Yes, it's a good point

Hi Doc, I didn't express correctly in my last post and you missed 
the point - I already know that Red will be prototype-based but the 
question is : will the object model implementation you'll use be 
flexible enough to permit you and/or the end-user  to easily extend 
  Red with other  new types, or change primitive functionality and 
semantics at some later time. The author of this article has done 
some studies and experiments about this fact and within his 16 pages, 
he explains how it could circumvent these possible limitations without 
sacrificing efficiency - even if I'm not advanced enough to take 
his word as truth per se. I thought it would be useful to you to 
see such writing before you committed to much material, based on 
your current architecture and internal implementation details - about 
which I don't know anything, I must confess. Sorry if this is more 
of an annoyance than a useful tip but I thought it could be useful 
as a reading to anyone interested in implementing some programming 
language - be it not fully Red related.

Red: I'm still working on both the compiler and the minimal runtime 
required to run simple Red programs. I have only the very basic datatypes 
working for now, no objects (so no ports) yet. I not yet at the point 
where I can give an accurate ETA for the first alpha, but I hope 
to be able to provide that ETA in a week.


Red string! datatype will support Unicode (UTF-8 and UTF-16 encoding 
internally). I haven't implemented Unicode yet, so if some of you 
are willing to provide efficient code for supporting Unicode, that 
would greatly speedup Red progress. 

The following functions would be needed (coded in Red/System):

- UTF-8 <=> UTF-16 LE conversion routines

- (by order of importance) length?, compare (two strings), compare-case, 
pick, poke, at, find, find-case
- optinally: uppercase, lowercase, sort


All the above functions should be coded both for UTF-8 and UTF-16 
LE.

Added floating point support to the SQLite binding

Entry Point RAW: 	Invalid or not in CODE section (possible Encrypted 
or Compress Executable)

I checked four additional DLLs, and the tool reports for all of them:

Entry Point RVA: 	00001000h
Entry Point RAW: 	00000400h

temp.dll is however:

Entry Point RVA: 	00000000h

Entry Point RAW: 	Invalid or not in CODE section (possible Encrypted 
or Compress Executable)

Entry point should be 0 (for now).

Pekr: I wonder if there's not an issue with the lack of entry point 
in the DLL, I just don't get why REBOL would choke on it sometimes 
and never the C apps (except your testing tool).

Can you check if your TotalCommander tool still spits out the error 
on Entry Point RAW?

yes, still in there:

Entry Point RVA: 	00000000h

Entry Point RAW: 	Invalid or not in CODE section (possible Encrypted 
or Compress Executable)

You can now provide an entry-point callback, see the commit log: 
https://github.com/dockimbel/Red/commit/8e7c1f84226b8a7ebfde0ec08136e88f566fb4bb

Entry Point RVA: 	00001A8Bh
Entry Point RAW: 	00000E8Bh

So, it's not an entry point issue...

What if you explicitly point to the current directory? Is that %.\temp.dll 
on Windows?

what is now latest temp.reds source? I got:

Compiling tests/temp.reds ...
Script: "Red/System IA-32 code emitter" (none)
*** Compilation Error: missing argument
*** in file: %runtime/win32.reds
*** in function: ***-dll-entry-point
*** at line: 204
*** near: [hinstDLL]

The callback attribute is added automatically to a function when 
passed as get-word. But there are some cases where  it needs to be 
manually set, like for the ***-dll-entry-point function from the 
runtime.

So far, my short-list of encodings to support are UTF-8 and UTF-16LE. 
UTF-32 might be needed at some point in the future, but for now, 
I'm not aware of any system that uses it?


The Unicode standard by itself is not the problem (having just one 
encoding would have helped, though). The issue lies in different 
OSes supporting different encodings, so it makes the choice for an 
internal x-platform encoding hard. It's a matter of Red internal 
trade-offs, so I need to study the possible internal resources usage 
for each one and decide which one is the more appropriate. So far, 
I was inclined to support both UTF-8 and UTF-16LE fully, but I'm 
not sure yet that's the best choice. To avoid surprizing users with 
inconsistent string operation performances, I thought to give users 
explicit control over string format, if they need such control (by 
default, Red would handle all automatically internally). For example, 
on Windows::

    s: "hello"		;-- UTF-8 literal string

    print s		;-- string converted to UCS2 for printing through win32 
    API
    write %file s	;-- string converted back to UTF-8

    set-modes s 'encoding 'UTF-16 ;-- user deciding on format
or
    s/encoding: 'UTF-16

    print length? s	;-- Length? then runs in O(1), no surprize.



Supporting ANSI as internal encoding seems useless, being able to 
just export/import it should suffice.

BTW, Brian, IIRC, OS X relies on UTF-8 internally not UTF-16.

Got my first real Red program working: 
    Red [] print 1
outputs:
    1


It doesn't look like much, but it validates the compiler + runtime 
from end to end, and at this point, it's really cool! FYI, the native 
PRINT here triggers a FORM (action) on the passed argument. No REDUCE 
yet (not implemented).

You made your point, but I have to counterbalance them for potential 
sponsors to Red. Nobody controls the Bitcoin supply, the limit is 
built into the system. You don't have to compute them yourself, you 
can exchange your other currencies for them

I would very much like to have a console, but it is not doable at 
this point (unless someone has a bright idea?). We'll add one as 
soon as possible.

Sure I speak for many who are [silently] watching this and waiting 
for it to mature to the point where we can usefully contribute.

Ashley: that point is closer than you might think. Even at bootstrapping 
stage, once Red get enough Core features, you and any other reboler 
will be able to add new libraries or port existing one from REBOL 
(should be trivial in most cases). That's not limited to mezz code 
though, you'll be able to add bindings to pretty much anything, protocols, 
provide Red plugins for 3rd-party apps (browsers e.g.), even make 
a View clone if you want (that one could even be a community project). 
:-)

For those who are excited about what Doc is doing, please remember 
to continue donating.  He's devoting all his time and work to Red 
at this point.

So, yes, there are a few of us waiting to contribute when Red reaches 
that point for us

Kaj: I might make macros context-sensitive, but I don't see what 
more I can do. The point of #system is to write Red/System code within 
the 'red context, so naming should be done carefully to avoid conflicts. 
But with a few context wrappers, you should be able to solve that, 
no?

Kaj: I might make macros context-sensitive, but I don't see what 
more I can do. The point of #system is to write Red/System code within 
the 'red context, so naming should be done carefully to avoid conflicts. 
But with a few context wrappers, you should be able to solve that, 
no?

Reading all the discussion about R/S source inclusion in the Red 
- it seems pretty complicated and confusing at best. Apart from the 
three options discussed on friday, it is the "least powerfull" one. 
It is not any kind of inlining R/S code into Red from the runtime 
point of view, hence I wonder, why it is not simply called an #include? 
I know you might want to two cases now:

#include %some.red
#include %some.reds


But that's distinguishable, and unifies the naming, as well as it 
does what the name suggests - it is just preprocessor kind of directive 
for including either the red, or r/s source into Red ....

Inline ASM: we might add that at some point, but you can already 
access some low-level CPU/FPU features (like stack manipulation). 
I will extend that in the future to support CPU in/out commands and 
direct registers reading/writing, so ASM support will be less necessary. 
Also, there's a cheap way to support it, adding the option to inline 
machine code directly in Red/System code flow (you would have to 
use an external ASM for generating the machine code). Something like: 
inline #{....machine code...}

Good point, I'll see how Doctor Manhattan renders in red shades. 
;-)

I can live without the line numbers, even in a R2 like error handling 
:) A lot of programming errors are development related and should 
never happen again once correct datatypes are passed on between functions 
so after this is done no further need for extra debugging statements 
here. User input is always wrong, they give wrong data and should 
be punished hard for that (Oh no that's Googles point of view) but 
the point is it should be tested to be what it should be and in that 
 way REBOL errors should rarely be reported by users. (just my 2cents)

(Please note that I'm deliberately using rather vague terms, as I 
only want to point at where the solution lies, but not suggest a 
concrete design of that solution, at the moment.)

Git is bloated, to the point that in the past we haven't been able 
to port it to Syllable. Maybe the core would be portable now, but 
we don't want it, because it's huge and complex and confusing to 
users. Fossil is much simpler

Under windows there is no common folder where the common.reds file 
resides - on windows common.reds resides in the runtime folder, so 
the #include file in the c-library.reds file needs to point to where 
that file resides. Likewise on fib and mand - they point to the c-library 
which I put into the library folder  that exists in the Red/System 
folder on the windows version.

Ok I see your point with the depedencies, different contexts could 
be annoying.

Good point and I totally agree with that. That's basically the plan 
for Red/System v2. But, as you say, it can become quickly very costly, 
so it needs to be done carefully (needs time) and *sparingly*.

This is the plan for handling numbers with decimals:

- decimal!: BCD
- real! or float!: floating point numbers

- money!: BCD or just integer with a scaling of 100 on input/output.

All numbers representable in binary floating points are rational 
numbers, but not all rational numbers can be represented (exactly) 
in binary floating point.

I've implemented floating point support in the SDL binding. This 
is used for audio conversions

what is this ABI about? Is that about supporting advantage of having 
HW floating point unit available?

It's basically unrelated to Thumb. It's not necessarily about hardware 
floating point, either, but it's a different way of supporting it

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.

The thing is that they made software so complex, that it has become 
extremely hard to point your finger at where exactly it goes wrong. 
We had to build Syllable to get an idea of some of those things, 
and then nobody wants to believe you

Public API stability: right, that's a good point in favor of a set 
of wrappers on top of current Red runtime API.

It's helpful to make a conceptual distinction between the host interface 
and the extension interface, even though for R3 they are currently 
related to each other and share a lot of the same code.


For the host interface, the host is the OS (more or less) and provides 
an execution environment that the R3 runtime runs on like a program 
(this is all metaphorical, but I'm sure you get it). The OS in this 
case could be something like Windows, Linux, some microkernel, whatever, 
or it could be an application or application plugin like Eclipse, 
Visual Studio, Notepad++, Excel, Firefox, whatever.


For the extension interface, R3 is the OS, the extension-embedded 
module is the program that runs on the OS, and that program calls 
the extension's native code like a library. The program source is 
returned by the extension's RX_Init function, and that program then 
wraps the native library code. The module source is loaded like a 
normal script (slightly hacked after loading to make it a better 
wrapper), so the script could be embedded in binary data along with 
non-Rebol stuff just like with normal scripts. You could even have 
Red and Rebol scripts in the same file (if they use the same embedding 
method) so you the data the init function returns can be like a Red/Rebol 
fat binary, metaphorically.


Given this, Red could either be (or compile) a host for R3; or it 
could be (or compile) a runtime library that implements the same 
host interface as r3lib, making it a drop-in replacement for R3; 
or it could be (or compile) an extension that R3 is a client of, 
returning R3 code that calls calls the compiled Red code; or it could 
be an alternate extension container, for extensions that return both 
Red and R3 code from the same init function, which would call the 
Red code returned, which would in turn call the same native code. 
The two languages could be integrated at any point in the stack, 
along with other languages.

I don't expect Red and R3 to have the same system model, because 
if they did there would be no point to having Red at all. Being able 
to have extensions that can integrate into both would be an unusually 
amazing bonus :)

Good point. I'll add instead of move them, then

Good point.

OTOH, that could be a good selling point for Red. ;-)

What point is virus scanning if you need generic signatures that 
it will let through?

The point of target names is that people can easily associate them 
with the set of config options they refer to.

sigh... it took this long to get to this point

A first pass at accessing the Etsy API: http://reb4.me/r/etsy


Works similarly to my Twitter API script (a few OAuth differences 
here and there). You can download it, or run it in place (do/args 
... [...Settings...]). As with Twitter, you start with etsy/as and 
go through the authorization process.  It has a few example methods, 
and an open method - etsy/api-call - that can call (as far as I can 
tell) every api function. Will try to document at some point.

After the mirror game and the chessboard interface, the Red compiler 
script and various cgi scripts and showing all how radio buttons 
work in VID, I can now introduce to you the application to play checkers 
(10x10 international, in dutch dammen). Not bad for a REBOL newbie 
right? Wait a moment with all of your nominations please, because:

There is a tiny issue left with the moving of the pieces when playing 
against the computer but it is minor compared to all other issues 
I have already fixed ;-)


You can download the zip file with the program here http://arnoldvanhofwegen.com/stuff/damscripts.zip

Program is started with do %damb.r and you can play after setting 
the color the computer has to play with on the panel you get when 
you click the top-left button. You can look under the hood and see 
the values the program gives the legal moves. You can put your own 
positions on the board and continue from that point.
Enjoy!

MaxV, the Prezi way of presentation is cool indeed. Only problem 
for me to use it is that you need to be online when viewing. Been 
hoping this woul dbe possible using REBOL itself. Btw can you point 
me to the code of the example with the moving road?

Henrik, It's PowerPoint. I make a slide with 320 pages. I asked myself 
not to use bullet-point to make it not a traditional slide.

He asked people to keep it short and to the point ...

Sorry, just tried to make a point :-)

No, that's another way to prove the point. You can just edit the 
time of your message. Do you want me to answer before the previous 
post? :-)

Maybe you can get the columns the same height again? No I just wrote 
it to point this out in case someone doesn't notice.

In my humble opinion, you see things from the wrong point of view. 
What source is released?  Rebol intepreter

Do you modify it? No, you just put the intepreter and you software 
in the same container (zip, encapper, etc.)
So you don't need to make your software open source.

I like Ladislav's point.  Many people have claimed that Rebol like 
Lisp, there is no difference between code and data.  So, your source 
code is just data for the interpreter.

Yes, that is why I do not think it is relevant to point to some unrelated 
case making some invalid point.

Agree to disagree, then. If you want to go to court to argue your 
point of view, please do, but I would like not to

I hope now it is clear where my point differs

There is no single truth here. There are a few realistically defensible 
positions, all of which have been argued extensively before.


The legal opinion of the FSF (publisher of the GPL) is pretty clear, 
by analogy to Perl or Java: all/most REBOL mezzanines are library 
functions to which a user script dynamically links. If the mezzanines 
are GPL licensed, the source to user scripts will have to be provided 
in a GPL compatible way.


Equally clear is e.g. Lawrence Rosen (IP lawyer) in articulating 
his legal opinion. Paraphrased: "linking is irrelevant for deciding 
wether the result is a derivative work" -- this mostly matches Ladislav's 
stance.


The whole point of this debate is not really ultimately deciding 
the resolution for that issue as pertaining to a GPL'd REBOL, but 
pointing out that, without additional clarification, the GPL results 
in a problematic legal uncertainty. This legal uncertainty may lead 
to quite the opposite effect of what many believe Carl actually intends.


So one very easy solution, is to include a few definitive clarifications 
along with the GPL.


Another, probably much easier, solution would be to simply sidestep 
this issue and use a different license.

Carl seems to be on steroids last days :-) Wonder if he is going 
to be back to active development too at some point ....

Kaj, I'm probably doing this wrong. All examples under MSDOS/Red 
fail with:

---------------------------
empty.exe - Entry Point Not Found
---------------------------

The procedure entry point wprintf_s could not be located in the dynamic 
link library MSVCRT.DLL. 
---------------------------
OK   
---------------------------

I don't have the required libs at this point so I'm expecting failure

That's a point. I would be glad to participate with other people 
in charge as my time permits.

 just point the camera in the decided direction
. "Decided" is odd there. Should it be "desired"?

GCam turn* on Automatic White Balance
 - *turns

The JPEG format is the common 85% JPEG for the iPhone.
 - This still sound to me like people use JPEG 85% of the time. 


Looks great John. Any further wordsmithing would be minor, maybe 
adding some prepositions and articles to make it sound more natural, 
but it's very good as it is.

Porting takes 5 minutes
 getting to that point takes a lifetime.

Graham, it should work on anything that has at least Android 2.2 
and an arm cpu. Moreover the APK contains additional build  of the 
R3 interpreter for arm cpus that have hardware floating point operations. 
I haven't made any benchamrks so I don't know if this is really performance 
advantage (in case of Rebol code) for Devices with such better and 
newer hardware.

at some point, the version will be incremented no?

maybe point to this, if you add symbols:


http://superuser.com/questions/462969/how-can-i-view-the-active-threads-of-a-running-program

Kaj: I'm looking at your %console-pro.red script and it's really 
enjoyable for me to see all the pieces of Red programming stack put 
together and working well, at this point of the project. Kudos for 
having add script file loading to the console! :-)

MaxV, I also agree that your involvement has been positive, and I 
always enjoy reading your posts :)  I also agree that it's great 
to offer more open channels of communication, but I think Andreas 
is 100% correct - links are preferrable to copied content.  Setting 
up a portal could certainly be helpful for anyone who prefers using 
that interface, but pointing to original content is critical.  The 
more sites that pop up and point to other important sources, the 
more easily people will be able to find what they need, no matter 
how they find their way into the community.  Helping to organize 
and guide people to the right places is helpful, but copying has 
all the problems Andreas pointed out.

We haven't needed one yet. Foundations tend to do better when they're 
for well-established projects, since otherwise they don't tend to 
get enough funding to cover even their own overhead. So the first 
part of a foundation-building plan would be to grow the community 
to the point where a foundation would be a good idea :)

Right at the point when it became appropriate for me to go to devcons, 
they stopped holding them in USA and I stopped having the money to 
travel outside USA. So unless my financial situation changes, or 
someone sponsors me, or visits me, then noone will meet me

Well, my greater point with it is its involvement in education. Your 
chat just now, with Scot and James, made me think some more about 
it.

View question http://synapse-ehr.com/community/threads/adjusting-a-text-list-starting-point.1447/

Next level !

Any suggestion about creating a dynamic built GUI ? I whish to create 
a GUI from a Block of data, each data is a button and each button 
has an action attached to it.
Could you please point me to some code to analize?
Thanks in advance

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

welcome to Rebol John, 


this group's etiquette is: "there are no stupid or wrong questions".


In case you ever wonder if you are asking too advanced questions 
at some point .... the fact that you are thinking of asking them 
here is an indication that you're still a candidate for this group 
 :-)

Endo -- thanks....That's a  useful starting point for a function 
that is capable of listing what the differences are.


Steeve -- 'difference on third was my first design ....But it fails 
on (say)
   obj1: make object! [a: 1 b: 2]
   obj2: make object! [a: 2 b: 1]

Maxim .... Nice!

There was no point in using parse/case since the comparisons were 
being done by strict-not-equal?, not parse.

i don't follow your point re: recursing from anywhere (i.e., from 
non-tail position)

aha, misunderstood your point

steeve: ooh, good point

I think this would be the start of something superb. If we can build 
a SPARQL like query interface on top of an associative db in rebol, 
we could simply point it to any of the open data initiatives and 
then go on the ride of a lifetime!

R2 is more ambitious about datatype conversion than the R3 extension, 
which only handles SQL datatypes that are directly compatible with 
64bit or smaller R3 datatypes. However, R2 doesn't handle floating-point 
datatypes, and R3 does.

but in those links ,i can not find database example! i read that 
link before ,i created html form and cgi as well, it is working properly 
... the point is when user enter input and click submit it goes to 
cgi page. i need save that input in database ...plz guid me or show 
me one example how can i save value from the form into db?

Any one knows how can we save value from the form into database?
 - sure, Pekr told you how to do it.


Your problem is that you do not do what Pekr told you to do. First, 
you need to create the form. Check: Do you really have the form?

Second, you need to create a CGI script (this is not the form from 
the first point, the form from the first point is not a CGI script). 
Check: do you really have a CGI script ?


Pekr told you that the example you posted was neither the form, nor 
the CGI script.

Case in point, one of our contributors recently made a developer 
edition of Syllable 0.6.7. It's much bigger than the standard distribution, 
but he's hosting it himself, so that's fine with us

I got the browser to be unresponsive again and tried to kill the 
process using the System Information Processes tab, but that didn't 
work and the info applicaton became unresponsive as well. At that 
point the mouse didnt work either and when I tried to send the OS 
a ctrl-alt-del, that didn't do anything.

The hosting is not the point, though. I can host files, but if it's 
an official Syllable release, I should have done all the quality 
control and it should be in all the usual places, such as SourceForge. 
If it's a contribution, the hosting should also be contributed to 
make that clear, and I can just link to it