r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Extensions] REBOL 3 Extensions discussions

Carl
19-Jul-2010
[1076x2]
Check R3 Chat. I'll be sending you a few notes.
Check your email.
Maxim
19-Jul-2010
[1078x2]
ok
know what they say....  "carefull what you wish for... you just might 
get it"   :-)

I asked for it  ;-)
Graham
19-Jul-2010
[1080x2]
@Carl ... I don't think the three or so people testing extensions 
are going to flood anything.
And surely the testing argument applies to R3 ... so where is the 
test suite?
Pekr
19-Jul-2010
[1082]
Wasn't testing suite publicly available? http://www.rebol.net/r3blogs/0125.html
Graham
19-Jul-2010
[1083x2]
I don't recall seeing it ... but in April 2008 I wasn't playing with 
R3
The method seems sound, but I think there could be a problem with 
the quantity of tests generated. Currently, with only five (of 56) 
datatypes tested, there are more than 22'000 test vectors, and they 
build exponentially. We may end up with more than a million test 
vectors for the final suite.
Gregg
19-Jul-2010
[1085]
Yup. But that's OK if it's all automated.
Maxim
19-Jul-2010
[1086x2]
yes, let it run for two days... do we really care?
it might even provide other insight on running such a heavy script
Gregg
19-Jul-2010
[1088]
Or give Carl the impetus to build a grid/ipc/distribution infrastructure.
Robert
20-Jul-2010
[1089]
Graham, SQLite uses over 2 Billion tests before doing a release.
Graham
20-Jul-2010
[1090]
for i 1 1000'000'000 1 [  insert db {select * from test where id 
= (?)} i ]
BrianH
20-Jul-2010
[1091]
The point is that 22'000 test vectors isn't much, and can be generated 
for the most part. We don't have to write them by hand.
Graham
20-Jul-2010
[1092]
Guys .. I didn't write that .. it's a quote from Carls blog
BrianH
20-Jul-2010
[1093]
OK, cool. So the point goes to Carl :)
Robert
20-Jul-2010
[1094x2]
Yep :-)
And, it's all about test-coverage, not about high number of tests 
triggering always the same code.
Graham
20-Jul-2010
[1096x3]
write %qt2.dll read http://www.compkarori.com/r3extend/qt2.dll
secure [ extension allow]
test


and this brings up a Qt window with a push button .. says "hello 
world"
Better than nothing :)
Looks like Nokia sponsored the development of PySide, the Python 
bindings for Qt4 .. some 300 odd functions etc.  Wonder if they might 
sponsor a R3 binding!
BrianH
20-Jul-2010
[1099]
There is a Python port to at least two of Nokia's cellphone operating 
systems.
Maxim
20-Jul-2010
[1100x2]
** R3 EXTENSIONS MILESTONE **
I have successfully mechanically generated  a complete r3 extension 
and test script, by simply parsing a C language .h file.
  

if you have a makefile ready for your extension, it will even compile 
the extension for you and launch the test script in a single pass 
of the engine.

this is based on the latest r3 A101 build.
TomBon
20-Jul-2010
[1102]
congrats maxim, THIS is a real milestone.
Gregg
20-Jul-2010
[1103]
Cool Max!
TomBon
20-Jul-2010
[1104]
open the door to prebuilt (logic condensensed) C libs will enhance 
rebol straight to the commercial 
software development.
Maxim
20-Jul-2010
[1105]
capacity of the parser will be the main focus for on-going development.


I already have the complete C language parse rules from an older 
project, so I'll be slowing importing the rules into this engine.
Gregg
20-Jul-2010
[1106]
Some good SWIG-like tools will helpe people a lot.
Maxim
20-Jul-2010
[1107]
using comments in the C source, you can give instructions to the 
engine on alternate bindings and rebol test code you wish to compile.


the advantage is that these comments are side-by-side with the original 
C source file, so its easy to maintain.
TomBon
20-Jul-2010
[1108x2]
I guess there will be a lot of more work and testing ;-)
what current limitations you have and in what timeframe you could 
solve them?
Maxim
20-Jul-2010
[1110x4]
the current code is a single ~16kb file,  so its not too large right 
now.


obviously as more types are added, this will grow, but since I'm 
using a "rebol-formatted intermediate source tree", its easy to improve.


the parser just generates a version of the C source in this "RFIST" 
format, and the generator only has to convert this into something 
else.


in time, we might even build different emitters for the "RFIST" data.
limitiations, well, just the scope of supported datatypes, both in 
C and in REBOL commands.
others than that its working very well.
one fun thing is that we do not have to use the C source types as 
the interfaces for the commands.

my next test is to build a generic object to parameter map.

so, if you have a C func declared as:
int myFunc (int a, int b)

you'll be able to call it from rebol using:

obj: context [a: 1 b: 2]
myFunc obj
TomBon
20-Jul-2010
[1114]
yes please! :))
Maxim
20-Jul-2010
[1115]
its funny how the extension API feels like writting assembly  :-D
Graham
20-Jul-2010
[1116]
@Carl .. you called my suggestion insane, and now you post this blog 
http://www.rebol.net/r3blogs/0327.htmlsaying that you will do it 
anyway!
Maxim
20-Jul-2010
[1117x2]
he's being pressured by everyone   :-)
he feels the love   ;-D
Graham
20-Jul-2010
[1119]
Ok, so join the asylum ...
Maxim
20-Jul-2010
[1120]
and my tests (with a fix or two)  and successfull builds probably 
helped him be a bit more confident.
Graham
20-Jul-2010
[1121x5]
daily or perhaps less frequently releases are the way to go
this is a genetic approach :)
And my other suggestion about releasing a linux version also still 
stands
The linux users tend to be more experienced and yet they are being 
excluded in this process
The rebol 2.7.7 View problems on linux were reported way back and 
it' s only now that they are being addressed ...