AltME groups: search

I don't see how a trampoline would work very well, because we're 
talking user written callbacks, so each would need its own trampoline

Anyway, forcing cdecl for all callbacks might be a better option. 
I would need to check first if there's no internal compiler drawback 
on this option.

Just thinking about a drawback for your proposition: Windows API 
expects callbacks using stdcall convention...

Red/System uses stdcall too internally, so forcing user to use a 
cdecl attribute for Red level callbacks is not natural. Need to think 
more about it to find a better option.

I don't think it is a good solution to put the burden on Windows 
users only.

I think it should be reasonable enough to choose cdecl when a function 
pointer is passed to a variadic function.

I haven't decided yet on the implementation detail, but my current 
plan is to use a R3-like approach, passing messages to a lower-level 
layer wrote in Red/System.

The ?? is the default value for cconv. When the compiler encounters 
a get-word!, it propagates the cconv from the function using it as 
argument.

How are you passing callbacks? Same way as with GTK binding through 
a variadic function?

I think that I will just accept both 'stdcall and 'cdecl attribute 
in cases like this where the compiler can't determine the right calling 
convention. I will also add a check at the end of the compilation 
to raise errors for unresolved calling conventions.

The default needs to be a non-usable value for the compiler to be 
able to catch unresolved calling convention. If it's cdecl or stdcall, 
the compiler won't report the error which can lead to stack corruption 
at runtime.

The current resolver only works for simple cases, basically, only 
when you're directly passing a function pointer as argument to a 
function.

I don't really see a connection between the function a pointer is 
passed to and the function that will eventually call it

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.

Let me have a look at the specs, I remember there was an edge case 
documented there...

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.

So that means that any function declared as 'cdecl or 'stdcall can 
now be used as a callback? Or can all functions?

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?

Well, having just "cdecl" or "stdcall" might not hint enough the 
reader that the function is used as a callback...

Answered that a few lines above: "the callback attribute was just 
meant to help the compiler figure out that the cconv has to be solved 
at compile-time."

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, ...).

If you were asking if a runtime conversion was done between calling 
conventions, the answer is no.

Kaj: I think after this discussion that dropping the whole callback 
thing should be the simplest solution. I would only add a 'cdecl 
attribute for functions that needs to be called from C code. Any 
function (with or without 'cdecl attribute) could then be used as 
callback. Would you agree?

BrianH: I need to correct a bit my answer to your question. Actually, 
there is a small code emitter dependency on the 'callback attribute. 
It is used to save special registers (edi, esi, ebx) to conform to 
IA-32 ABI. It is only needed when providing callbacks that are invoked 
by the OS or external libraries.


I should be able to keep this feature in the new revision while making 
it transparent to the users.

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.

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

Since SQL is a dialect, a lot can already be done that way

I have put the current contributions on a new page: http://www.red-lang.org/p/contributions_21.html

I haven't found a way to see any source code on these fossil pages

Janko, there's a button that will fill out the CAPTCHA for you

I've added a quick-start SQLite example

Added a WAV player example to the SDL binding

Max did a FBP implementation in R2 but what was missing was the multithreading.

Hm, I haven't done anything with NTLM. I'll have a look at the docs

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:

A new group for discussing the Topaz language.

Graham, you'll probably have to wait for a good answer to that question. 
:)

I guess it'll be a year or more ... before the answer arrives

graham, topaz is a silicate based gemstone, with the correct impurities 
it could morphe to topaz_red.

as you can see here: http://en.wikipedia.org/wiki/File:Topaz_red.jpg 
  :-)))

this was a truly accelerated year...

LOL, yes, but only if mutation appears also within a accelerate year.

@Gabriele Do you have a home page or is it Github project hosting 
as a home page ?
Thx

nve: i don't have a home page yet, except for the try-topaz.html 
thing. so github is the place for now.

Do you have a timeline for your project ? A goal to reach ?

People are asking lots of questions about Topaz (because it is related 
to Javascript ;)).
Thanks for your lightening.

I don't have a timeline because I can't work on it 100% of the time.


I have many goals. One is to make creating web applications easy. 
I'll repost a message I posted earlier on a different group:

even you don't work on it 100% time, it would be nice to know what 
is next, you can write what is in your mind for next step, like a 
to-do list, without given exact dates.

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

That would be quite a change for a reboller, in how we perceive rebol 
code, no?

I find this better:

x  =>  string!



->    looks more like a "move to here" (which is why they used it 
for C pointer struct dereferencing IMHO)

=>   having an = symbol, looks more like a "make into"  (for which 
"to" is a synonym).

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

the Other alternative I see is using   <-  , as in:

>>  x <- string!    

but with endo's comment, its very misleading to read.
>>  x  <-  t

it looks like an assignment.  (put value of t within x)


so maybe standardizing on a first character which means, this operator 
is an in-place modifier, might be a good idea...  it might also allow 
a new class of series operators.
-----------------------------
with:
:=   to
:<   append
------------------------------
label: "prefix-" :< "text" :< "-suffix" 
x: 1
y: 3
x  :=  string!
x  :< "test"
x:  label :< 1  :<  y: "2"  :<  (y  := string! )
-----------------------------
x == "prefix-text-suffix123"
y == "23"

To op or not to op
 ...is suddenly very confusing.


For general use I would keep them as regular funcs, but perhaps add 
special sigilized op! versions. I like the regularity of funcs when 
generating code. I use the op approach in my dialected CAST func. 
e.g.

  cast [a to tag! b to block!]

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

I like the experiment. I was always a bit thrown off by the order 
of IN

AS might be a better name for the operator instead of TO. IN as an 
operator with that argument order makes sense.

In REBOL I often avoid using operators when they would require parens 
to manage precedence, because parens have overhead there. This wouldn't 
be the case in a compiled language like Topaz.

I thought we have something of a convention to use AS for possibly-non-copying 
conversions?

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

Well, a lot of the language patterns used in REBOL come from its 
interpreted implementation. We don't use ops much in complex code 
because of paren overhead, but we use ops in simple code in R2 because 
the lookup is more efficient because it's special-cased. Compiled 
languages may end up being shaped differently, especially for optimized 
code. Still, AS for possibly-non-copying conversions is still more 
of a proposal in REBOL rather than an actual. AS as an operator version 
of TO would work there too. You could even do it directly in R3 if 
it weren't for the reversed arguments.

Also, Topaz' main current purpose is to compile to a (semi-)interpreted 
language, so you may still want to take interpreter patterns into 
account

Nope, not as long as parens don't have overhead in JS. JS, Lua, Python, 
Ruby, they're all compiled, even if the compilation result runs on 
a VM.

But the copying thing is a good reason to have AS be different than 
TO.

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'm very pleased with not having to remember precedence rules in 
REBOL, so I think of it as a brain optimisation instead of an interpreter 
optimisation

even when  = has higher precedence than executing a function?   come 
on, a little bit of precedence would make a lot of REBOL code simpler 
to write.

a: "eek"
b: "wtf"

if append a  "ouch" =  append b "ouch"  [ a ]  ; ERROR appends boolean 
to a string, so is always "truthy"
== "eekfalse"


this kind of thing makes me go mad !  (there are sooo many other 
examples  ;-)

It's an inconvenience, but remember a whole stack of rules, which 
never succeeds, is a big inconvenience

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.

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.)

Max: if append a  "ouch" =  append b "ouch"

I wonder how would you ever find that readable.

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.

I guess the common use:

   if 'word in context [...]

makes sense, while the common use:

   var: (...) to string!


is a bit unpleasant. OTOH, maybe this'd give a reason to the various 
to-* functions, so you'd use

    var: to-string ...

still, "to-string" is not a verb... so, i'm not convinced yet. :/

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!

I like TO better than a symbol, which would also be non-standard, 
but maybe we can have both

Gabriele will give a presentation about Topaz during Software Freedom 
Day 2011, wednesday 14th september, at the Centrum Wiskunde & Informatica 
(CWI), Science Park Amsterdam: http://www.softwarefreedomday.eu/

That is a very good news!

I like this idea print  "hello " .  myvar . " !" or print "hello 
" + myvar + " !"  over the print rejoin ["hello " myvar " !" ] ... 
In web area a rebol inspired language using more "advanced" less 
pompous string concatenating method will be noticed I think...

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 ?

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.

gabriele I think the perl/php  apraoch print "myvqr bla blah myothervar" 
is not in your plans neither ... Well I gived you just a list of 
the kind of things I think rebol could do better no offense ...

I've significantly reorganized the Topaz source code. A bit more 
manageable this way.

For a sneak peak of how it works, see the comments in: https://github.com/giesse/Project-SnowBall/blob/master/topaz/types/function.topaz

It was a race against time... but Topaz is now ready for the SFD. 
:-) See Github for all the changes.

Now... i need to put together a couple slides... :-)

I'm sorry, it turned out that the venue has a firewall that blocks 
almost everything except HTTP, even outgoing connections on the wired 
network, so we couldn't get through with AltME

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

we also have SFD in the Singapore National Library. If u could share 
the slides by tomorrow, I would try to prepare myself for a talk 
also.

It would be nice for future talks to have a PC screen infront of 
the presenter so that they don't talk to the screen.

Heh .. finally a case for power point!

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 :)

I'm planning to do something like a Hangout on Google for a Q&A for 
people here that were unable to come to the conference. When would 
it be a good time? Any other suggestion other than Hangout?

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.)