AltME groups: search

Well, it depends if the function taking a function pointer is invoking 
it directly or if it's passing it to another function (local or imported). 
In the former case, the compiler can set the right cconv itself, 
in the latter case, it can't and need some help from the user.

The inferer is very simple, it just looks at the cconv of the calling 
function and propagates it to the callback. If the callback has already 
a cconv defined, it checks if both cconv matches, and raise an error 
if it's not the case.

Ok, these are the changes I will make today wrt cconv resolution:

- 'cdecl and 'stdcall keywords will be accepted as function attributes.

- 'callback attribute remains, it lets the compiler decide on the 
cconv to apply. If it fails to solve it, an error will be raised 
and user will have to manually set it instead (replacing 'callback 
by 'cdecl or 'stdcall).

then we need typesets and attribute sets :-)

I think I see your concern. It might be probably less confusing to 
leave the 'callback keyword mandatory for "callbacks" and accept 
'stdcall and 'cdecl as additional attributes, but it is a bit more 
verbose also.

What's the difference between a cdecl callback and a regular cdecl 
function?

I thought so, so why not drop the callback attribute and let the 
programmer decide whether it is used as a callback or not?

But in such case, users woud have to always set the cconv manually 
and the compiler wouldn't be able to help catch errors.

The current 'callback attribute triggers the compiler inferer and 
cconv errors.

If we get rid of 'callback attribute, then only 'cdecl attribute 
will be required and it will have to be set manually everywhere it 
is needed.

This might be the best option currently, as it would just require 
users to change 'callback to 'cdecl in most cases and just drop the 
'callback attribute in other cases.

Then we could just specify 'callback if we want the system to guess, 
'cdecl if we know it's that, and nothing if stdcall.

No, it can't work that way. If 'callback is used, then we need the 
error system to catch the unresolved cases, so we need to set initially 
every callback function calling convention as "unknown" instead of 
stdcall. For the unresolved cases, the user must be able to set manually 
the convention, so he needs both 'cdecl and 'stdcall to be accepted.

I guess I just don't understand well enough what is done to support 
callbacks. If you specify a 'callback attribute, is there a shim 
created that marshalls arguments from the callback calling convention 
(cdecl or stdcall) to the internal calling convention of the function 
(stdcall or cdecl)? And if you specify 'cdecl or 'stdcall, does that 
affect the internal calling convention so that no shim is required?

When you use 'callback attribute on a function, the compiler just 
tries to determine what is the appropriate calling convention to 
apply internally to the callback function. In order to acheive that, 
it checks the first caller function that will take the callback as 
argument and set the callback to the same calling convention. This 
part is done by the compiler's front-end, which just tries to set 
the calling convention correctly (just a word! in an internal block!), 
nothing else.


The compiler's back-end just emits the right code for whatever calling 
convention the function has (cdecl, stdcall, syscall, ...).

I have pushed a new revision of Red/System where the 'callback attribute 
is removed. Also, 'cdecl and 'stdcall are now accepted as functon 
attributes. I will update the specifications accordingly later today.

I can create and close an SQLite database now

Now I can execute SQL statements on a database, and process the results 
row by row with a callback

I copy/pasted it do text editor and was able to login. The code for 
GTK looks very nice

I am using Chrome 14 on Win7 and have no issue reading the captcha.

There are sample WAV files, and BMP files for PeterPaint, in the 
SDL documentation

Implemented the SQLite type system and stepwise query processing

Values can now be extracted with optimal efficiency and control

Precompiled SQL statements can now be bound and rebound to external 
parameters

I don't know if anyone has tested it, but Red/System should approach 
the speed of C. So that would be somewhere around the speed of C++ 
and such somewhat higher level languages

Kaj,   I have just started to look at CURL for NTLM.   Is it just 
grab the NTLM value from the headers and pass it with CURL as with 
HTTP-Auth?  Has anyone / everyone done this already?

I appreciate it. I will try a few attempts when running behind the 
firewall.  I want to put together a simple regression package for 
a web site using CURL and REBOL and/or RED.

Have a look here at a third, under Passwords and HTTP Authentication:

Implemented horizontal and vertical box layouts in the GTK binding

Normally a button needs more than one parameter, so it would always 
have brackets. But here they're only used as examples, so they only 
have a display text and the brackets can be left out

After having a quick glance at it, at least for utf8 it's quite basic 
and does not take any of the above overlong combinations into account.

I never liked either GTK or Qt. The reason I'm binding one anyway 
is that we want native platform user interfaces for Red. Linux and 
BSD don't have a native interface, but if you have to appoint one, 
you have to appoint two: GTK and Qt

Basically, to bind a C++ library, you have to write two bindings: 
one from C++ to C, and then one from C to your target language. This 
is because only C++ knows what C++ objects mean, and C++ claims that 
its object classes are a program's interface

For generic libraries, binding tools exist, such as SWIG and SIP. 
Unfortunately, they don't solve the problem but only assist a little, 
and the result is very bloated

Since a few years, Qt and KDE use a new tool: Smoke. It's more automated, 
so it looks like it can generate a C interface without writing C++ 
yourself. However, the cross-compilation problem still exists. Because 
the tool is so generic, the bindings it generates are also quite 
bloated and probably otherwise inefficient. In any case, it's just 
the first step for a Red binding, because I put abstraction layers 
over my bindings that are much more REBOL like

So I chose GTK to support as the "native" GUI for Linux and BSD. 
It can also run on several other platforms until we have native support 
for those

I'm not planning to fragment the effort by doing a Qt binding as 
well, but I did evaluate it, and the decision could change if I would 
be funded for it

TL;DR: the creators of C++ and C++ compilers decided that the world 
was not complicated enough, so they worked hard to make it more complicated.

It discusses 0MQ and shows SDL and GTK, but it's a primitive Hello 
World example when the GTK binding was only a week old, and callbacks 
in Red weren't fixed yet

BTW, do you plan to make a small documentation on the GTK+ binding 
API and/or a dedicated web page?

Thanks. I'm limiting the documentation to the examples for now. I 
have to choose between writing documentation or more bindings, and 
I need the bindings

Implemented TEXT and AREA styles, based on the GTK text view widget

I can't implement things such as GTK sliders and progress bars, because 
they use floats

That's a pity, because Jaromil requested slider and file selector 
widgets from me. When he has those, he can start using Red for a 
GUI for his Tomb security tool

I understand the frustration...If it could be added in 2-3 days, 
I would add it now, but a complete support would require much more 
time. I will try next week to make a more accurate evaluation of 
all the additions and changes required in Red/System compiler for 
supporting float numbers.

Implemented SECRET style, for hiding entering passwords and such

Both single and double precision floats will be necessary to interface 
with other subsystems

And that can't be done by linking to a math library?

Implemented activate action for FIELD and SECRET styles, so that 
they can respond to pressing the enter key

According to Twitter message, Doc got simple program compiling and 
running on Linux ARM. Nice and congrats :-)

And the meaning of life, of course

Implemented all the needed GTK constructs and a convenience function 
for actually extracting the text content from an AREA widget

Added dynamic scroll bars to the AREA widget and normalised its appearance 
like other input widgets

The obvious defaults and accessors that you would expect often aren't 
there

thank you very much kaj and dockimbel ;-)

Nice new features are side-by-side diffs and support for symbolic 
links

It does Flash and everything

Thanks. It's remarkable how big the gap is between the low and high 
hanging fruit. I've spent ten years on Syllable and REBOL, and three 
hours on this browser so far, including the WebKitGTK+ binding

Reviewed some Python, Ruby and Haskell bindings for GTK, and they 
all look like my Goodbye Cruel World example in various incarnations, 
instead of my Hello World example :-)

GTK's, and other IDEs', idea has always been that Glade, and now 
a newer interface builder, makes it easier, but combining a generated 
XML interface definition manually with some code language doesn't 
compare to Red/System

You can't reuse a function name in Red/System. `printf`and `free` 
are already defined in the runtime source code (%red-system/runtime/). 
If you provide alternative names (not used by the runtime) for those 
imported functions, it will work correctly.

Being able to make GUI apps on Android requires at least two more 
steps:
- have Red/System linker be able to generate shared libraries

- build a generic Java bridge to be able to instanciate java objects, 
invoke methods and receive events

I finally find some time to read Red/System doc, and I have a novice 
question - what is basically the difference of cdecl or stdcall? 
Respectively - when wrapping API stuff, how do I know which one to 
use? I expect this area is for more skilled C developers, than occassional 
interface users?

what is basically the difference of cdecl or stdcall?


See this wikipedia page for some basic info about calling conventions: 
http://en.wikipedia.org/wiki/X86_calling_conventions


Respectively - when wrapping API stuff, how do I know which one to 
use? 


When you're wrapping an API, you should find out how the library 
was compiled, and infer from that what calling convention is required. 
Most of C libs are using cdecl, while the Windows win32 API uses 
stdcall.

The NDK supports compiling to 3 different native formats right now 
- two ARM platforms, and x86. You can create an APK that supports 
one or more of these platforms. The binaries are packaged into an 
archive, with the binaries of different platforms put into subdirectories 
in that archive. When an APK is installed, only the binaries for 
the supported platform(s) are loaded.

In a lot of ways, Android reminds me of the Oberon System. You don't 
install apps, you install system services, that for some of the types 
of services provide a UI, and for other types of services provide 
an API or task execution model.

Go for 2.0, and you'll cover almost everything. Certain Red facilities 
could require more recent versions, but between 2.0 and 2.2 there 
were mostly just features added, as far as native code is concerned. 
If you support pre-2.3, you might as well set the baseline as far 
back as 2.0.

There are a lot of people still waiting for their manufacturers to 
provide upgrades from 2.1 to 2.2, so 2.1 support is a good idea. 
The main thing added in 2.2 was the Dalvik JIT compiler, and that 
doesn't really affect native code that much. The NDK docs have a 
pretty good changelog that tells you what was added in each version.

I will stick with ARMv5 until we rewritte Red/System in Red and add 
a code optimizer. Such optimizer will be able to generate v6 and 
v7 specific code when required.

Android lets you bundle seperate binaries for ARM5 and ARM7 support 
in the same APK. Which binaries get loaded depends on which level 
the phone supports, though if there's no ARM7 binary the ARM7 phone 
can run an ARM5 binary. If you want to do the progressive use of 
ARM7 features if ARM7 is available, it's best to let the APK do it 
for you. I don't think that there are any ARM6 devices for Android, 
especially since the NDK doesn't support them, but if you want to 
add ARM6 support for other platforms then cool.

Well, I am not doing the ARM port only for Android, I target also 
iOS and some embedded boards (like e.g. the Raspberry Pi).

I am pretty sure that we will find some ways to combine Topaz and 
Red at some point, once both get more mature.

But what about concentrate all the effort on one product ?


We all have different goals. My main goal is to be able to try out 
experiments (like, what would it be like to add feature X to the 
language?); there's no way I can do this with R3. Also, I don't want 
to program in C (so, again, R3 and Boron are out).


My secondary goal is to simplify creation of web and mobile applications. 
R3, RED and Boron do not run inside the browser; RED may be able 
to target mobile platforms eventually, so we may be able to collaborate 
here.

What is next is completing Topaz. The current version exists only 
so that I don't have to write any JS code in order to write the "real" 
Topaz. If you look inside next/ on the repository, i need to add 
all the datatypes and the natives, then write a translator that turns 
all that into something the current compiler can digest.

I was thinking about this:


In Topaz, you can make an op! out of any two-arguments function! 
(or native!). So, would it make sense to define IN as an op! rather 
than a function? Ie:

   'word in context

rather than

    in context 'word


The problem with it is that, contrary to +, * etc., there is no visual 
clue that IN is an op! rather than a function. However, the same 
can be said for AND, OR etc. in REBOL.


Which lead me to think: maybe the fact that the name is not a verb, 
but a preposition? In that case, should TO also be an op!?

    x to string!

rather than

    to string! x

Making IN and TO as OP! looks ok.
=> looks better than -> but it a bit similar >= and <=

I'm not sure if it reduces readability. Especially if we put string! 
value in a word (I'm not sure either if anyone uses this)

;rebol
>> to t 5
== "5"

;topaz
t: string!
x => t

Having the ability to create operators would be a good first step 
to deside, which operators makes sense, and who don't.

That would be nice, but this is also a Topaz group, and that's a 
REBOL convention :)

The big problem isn't an interpreter or copying thing, it's a syntax 
thing. If Topaz keeps the same evaluation precedence as REBOL, operators 
are going to continue to be awkward. The reasons behind the REBOL 
precedence rules are sound, and derived from the interpretation method, 
but if they are emulated in Topaz we'll still have asymmetry between 
the left hand side and the right hand side of an operator, requiring 
parens to resolve. Even if they don't have runtime overhead, we still 
have to type them. Not necessarily a problem, unless Gabriele thinks 
so :)

I don't find C's precedences to be that far off the mark of the most-commonly 
usefull pattern.  I don't have to write parens nearly as much in 
C than I have to in REBOL, its like a 10 to 1 ratio.  Do I feel like 
precedence is actually helping me.


its also a problem to me that rebol's clean syntax gets bloated by 
all those (relatively) useless parens.  


Add the fact that Compose will often bite you in the arse because 
of these (I do a lot of run-time code building and compiling in many 
of my apps) and its just gets really complex for nothing.

My C book falls open at page 53, as all of them do. It's just to 
hard to remember, lots of programs have superfluous parens "to be 
sure", and it's accepted that some of C's precedence should have 
been designed differently

See, all this is the reason, I think, why Carl never allowed creating 
new operators. :) (Aside from what looks like an optimization in 
R2, I think R3 works like Topaz in this regard and could easily allow 
custom ones.)

Brian: a clarification, Topaz is both an interpreter and a compiler, 
and although you can compile whenever you need speed (so in principle 
there won't be much need to manually optimize functions for the interpreter), 
in most cases you're running in an interpreter very like REBOL.

The issue of parens: i think that no matter what the precedence rules 
are, you'll find cases where you need parens.


Now, one of the things I want to try doing in Topaz is TCO, so maybe 
parens will have less overhead in the future than in REBOL, but it's 
hard to predict whether this is possible at all in the interpreter. 
They will probably not have significant overhead if you compile.


I vote we worry about readability first though, there's always going 
to be alternatives when performance is required. (Eg. the fact that 
something is available as an op! does not mean that it is not also 
available as a regular function; like in REBOL you have both AND 
and AND~. In fact, Topaz requires that you pass a function! or native! 
to make op! - so such function version has to exists anyway.)

That might be a drastic announcement. Letting = have higher precedence 
than the rest could be a good idea, but might be hard to implement 
and/or have performance hit.

Endo: think about the fact that the (...) is usually a long expression, 
but more importantly, there is no clue that TO is an op rather than 
a function, other than it not being a verb (which is not obvious).


The IN case is much easier to read, and IN is used in a similar way 
in other languages. TO might confuse both rebolers and non-rebolers... 
:)


I still like the idea of them being ops, i'm just worried about it 
being too unreadable and forcing parens most of the time. would anyone 
prefer using some kind of symbol? eg. similar to the <- suggested 
above.

Normally all op!s are somehow related with math, as we can consider 
equality tests (=, !=, > etc) and logical operations (xor, and etc.) 
as math operations.

TO and IN are different by this way, they are not related any math 
operation, they don't test, they don't calculate anything.

And one of them should have a precedence the other, or we should 
use parens, or can we say always left-to-right:

>> o: context [a: "3"]
>> 'a in o to integer!

arriving to do something like that in a rebol inspired script language 
would be terrific ... I know I'm just giving some thought and no 
code ... well ... I have not your talent for those thing :)

oh last remark ... I noticed most of the time scripting language 
tends to be differenciated by their affectation symbol  example lua 
use var ::= 1 rebol var: 1 perl var= 1, PL/SQL var:=1;  etc ... I 
like the rebol way of affectation and since that one of the sign 
of a rebol script I think it's important to keep in in spin off languages 
...

ok one last remark with red, borron, and red isn't that too much 
spin off language to handle for this community ? I understand there 
is a lot to research on this very interesting field ... but don't 
you fear that those project  will in a short term stop growing cause 
complexity level reach and there is noone to keep them on the progressing 
curve. Can eventually  those project be merged into one single project 
keeping the other two less advanced  as research ground and the BIG 
thing being granted with the best ideas proven in the "research" 
project ?

I fear that being 3 totally seperated projects on their own they 
won't liveon ... and somehow collide  ... Ok I'm not clear on this 
...

Shadwolf, something like "bla" . "bla" . "bla" cannot be optimized 
in an interpreter like Topaz, moreover, why the hell should i have 
to write . a hundred times and have an error when i forget it? So, 
no, you won't get this in Topaz.

Re: SFD: I hope to have something to demo as well, but i can't guarantee 
that as Topaz still has a long way to go before 1.0. Worst case, 
i'll just talk about it in general and accept questions.

take them as overall general comments and particular taste of someone 
used to program in around 20 languages ...

And the slides are going up on github too ?

I'll try to report the Topaz and Red talks here tomorrow

The presentations of Gabriele and Nenad were great, and we also had 
a good time afterwards. We thank them both

Right-click and then select rewind takes you back to the beginning.

Graham, the windows pc that was there did not have a second screen. 
My laptop has DVI, not HDMI, but only digital DVI, and the projector 
(or, at least tha adaptor that was there) seemed to want analog. 
So I'm sorry if you're looking at my back most of the time, but it 
was hard to do anything without looking at the projector screen :)

onetom: I used Keynote, it can export to a few formats, including 
HTML (by just making PNGs, so it gets pretty big). I can also provide 
the keynote file if useful. (Unfortunately, I was very tight on time 
and was unable to do this in Topaz itself.)