REBOL3 - !REBOL3 Priorities (Project priorities discussion [web-public])

Return to Index Page
Most recent messages (300 max) are listed first.

383MaximI've been under that impression myself... but haven't found an exact solution.19-Dec-09 0:19
382BrianHWell, I think I found the solution - it looks like Carl's assesmenmt of dylibs was wrong. Solutions posted in reply to him in chat.18-Dec-09 21:23
381Jankowow18-Dec-09 21:08
380BrianHWow, that explains why Apple has to sue developers for using undocumented APIs instead of just not exporting them.18-Dec-09 18:19
379PekrSome explanation:

"Back to OS X, the problem is that they're not really libs, they're .a's. This ev en appears to be the case when -dynamic-lib is used.

I should mention that I've had -dynamic-lib built OS X libr3 and host working fo r several days. But, the libr3 isn't in the form I want, because it's not intern ally linked and resolved. Examining it with nm it looks like just a concat of .o files.

Specifically, I want all internal symbols resolved, and I only want to export th e library interface.

If OS X only builds libs (dynamic or otherwise) as concatenated .o files, that's a serious breach of coding ethics! There are two reasons:

1. it means I can link against the internal interfaces - a serious short circuit in code encapsulation rules.

2. it means I can discover the entire internal structure of any product... say I want to peek inside Photoshop to see how it does something.

If I nm a lib that's been properly prepared, I should only see its API, nothing else. So far, this has not been possible on OS X.

I suppose I could easily confirm this by nm'ing some of the various apps I have on OS X and checking if I can see their internals. Let's hope not. "

18-Dec-09 8:34
378PekrGuys, there's a trouble with OS-X or so it seems. Any experienced OS-X coder to help? Message from Carl on R3 Chat:

"I must set OS X on the back burner... I've wasted far too much time on it.

There are three choices on it: 1. find a tool that does what I need 2. make a tool that does what I need 3. join all the sources into one large .c compile

Note that gcc -fvisibility=hidden does not work, nor does __private_extern__ wor k either.

I've got to get on with other projects now. So, if you happen to find the soluti on, let me know. (PS, yes, using GCC > 4.0.)"

18-Dec-09 8:24
377RobertI try all to keep away from C++ these days. It just gives to much hassles when going from one compiler to the next.8-Dec-09 7:46
376BrianHSo far, that is - see recent blogs for details.7-Dec-09 20:37
375BrianHJust being able to compile the host source with a C++ compiler would be sufficient - having declarations still work, for instance. The rest could be handled with shim code, basicaly what most of the host code is anyways.7-Dec-09 20:17
374BrianHAs long as the host code can be integrated into existing C++ code that's good for me. I'll be testing that ASAP.7-Dec-09 20:15
373Maximso far, I really like the Device model, there's nothing like C OOP without the ++

Exactly like the Amiga philosophy used to be. :-)

I guess C++ coders will just be screaming as to why this isn't all classes and objects... but its simple to code in any case

7-Dec-09 10:18
372MaximMSVC express edition... the free version.7-Dec-09 9:50
371RebolekOK, and what compiler have you used?7-Dec-09 9:49
370MaximCyphre has reported compiling on code::blocks (don't know what OS)7-Dec-09 9:46
369Maximon windows... I don't have my Mac setup for compiling yet.7-Dec-09 9:45
368RebolekMaxim - on Windows, or some other system?7-Dec-09 9:45
367Maximwell, for those of you who are on devchat... you can see my (humorous) host-lib compilation post there, but for all others... just I just want to tell the world that...

ITS ALIVE!!!! hehehahahahaha (evil grin and laugther)...

yep, I am on the short list of lucky individuals who got the host code, and it compiled the very first time I tried, so, mission accomplished and congratulations to Carl.

7-Dec-09 9:37
366Maximit took me just a few hours to have OpenGL running in an extension.... which includes downloading all the OGL libs, and C compiler and stuff.19-Nov-09 15:45
365Maxima lot of the stuff is already coded... it just needs to be translated for R3.19-Nov-09 15:44
364Pekr... so you want to do in few months, what was not done in 12 years of View's existence? Cool then :-)19-Nov-09 15:43
363Maximgive me a few months ;-)19-Nov-09 15:38
362PekrSo Max - when do we get FullHD editing in R3? :-)19-Nov-09 15:38
361Maximshake still today is preferred for very large effects shots... it can layer 500 full frame cinema images (2048p or more) using a few hundred megs of RAM. other softwares need 8GB of RAM just to handle 10. and render exponentially slower.19-Nov-09 15:37
360Maximnow.. you've got stuck-up companies like autodesk litterally controlling the whole industry with parties which would make your grandma wish she could leave early. ;-)19-Nov-09 15:32
359Maxima VERY cool and somewhat, excentric, group of people hehe... nothing real parties at tradeshow events like siggraph... usually where the most sought after events... S&M show with boobs on fire :-) nude circus acts. world-renowned dj's doing the music... ahh... those where the good times.19-Nov-09 15:31
358Maximyep. but shake's technology was embeded within other apple tools. the original nothing real guys still work at apple, all these years later :-)19-Nov-09 15:28
357HenrikThey still sell Shake? I thought it was discontinued a couple of years ago.19-Nov-09 15:27
356CyphreRegarding JIT/VMs: Recently I spent some time looking into this area. After the short investigation I believe JIT compiler which can be really useful(and fast enough) for Rebol can be written in kilobytes of code not megabytes.19-Nov-09 15:14
355Maximyes, in R2, globs is such an engine, and it works very well.19-Nov-09 15:08
354Maximpekr... wrt shake... and what do you think the graph does ? ;-)

the graph is compiled in real-time everytime you change its structure. you can create your own nodes and add them to the engine, using the graph itself as a visual development platform.

as I said, I worked for those guys... I have an intricate knowledge of how it works. I also implemented a REBOL implementation of shake callings its rendering engine and intepreting its (C) Header files to integrate all the nodes. :-)

19-Nov-09 15:07
353CyphreMaybe I'm missing something but you can do graph-based processing even with R2. There is really no special needs at the low-level.19-Nov-09 15:06
352PekrShake is not good because of LLVM-like low level imo, but because of properly Graph based GUI. Now allow us something like that for View, and you get-me-interested :-) 15:03
351Henrikalso FreeBSD, it seems19-Nov-09 15:03
350Maximbtw it looks as though I might get some funding to build Elixir :-D19-Nov-09 15:03
349HenrikAFAIK, much of OSX is moving to LLVM.19-Nov-09 15:03
348Maximfor elixir, for example, this would be extremely beneficial.19-Nov-09 15:02
347Maximsure, its not for the host, but its still not huge, and makes for a nice feature I'd add in any of my speed-critical applications, if I had access to it.19-Nov-09 15:02
346Pekrif some compiler adds more than 100KB to REBOL, then it is a no go :-)19-Nov-09 15:00
345Maximshake, one of the most high-end visual effects software in the world, uses a system just like LLVM within their software and it made it much faster than all the competition because of it.19-Nov-09 15:00
344Maximsouce code is 7MB, but probably includes a lot of stuff we can trim for our specific purpose. the binaries are big wrt rebol, so it can't part of the host code(unless brian can build a very slim version of it), but it would make for a very nice extension.19-Nov-09 14:59
343Pekrhow big is that runtime?19-Nov-09 14:56
342Maximso you code in a language similar to REBOL, but end-up with compiled code which is linked dynamically in the host...19-Nov-09 14:55
341Maximit would make for a powerfull extension, where we could simply run a rebol dialect like Rebolek's REBOL syntaxed-C and compile it in real time through an extension which serves as a jump vector manager.19-Nov-09 14:54
340PekrOr you, as a dev. simply use LLVM to create REBOL executable? And as you have ti LLVM abstracted, you basically code to one host environment? I probably don't understand the model correctly ...19-Nov-09 14:52
339MaximLLVM is a compiler, which you can control in real-time and easily embed.19-Nov-09 14:52
338Pekrso it is not a compiler, it is a virtual machine environment, no? What is the advantage here? REBOL is its own VM - if we get it to every platform, why would we need LLVM? How big is actually LLVM?19-Nov-09 14:51
337Maximalthough we could all of this ourself... LLVM is a nice framework to make all of that easier.19-Nov-09 14:35
336Maximwe could add JIT compilation to rebol, we could have REBOL based extensions which are JIT compiled in real-time, for example :-)19-Nov-09 14:34
335Maximmesa3D is using it in their driver engine to convert graphic calls to any GPU instructions... on the fly. implementing a driver becomes just a question of providing LLVM instruction maps... although not trivial... still much simpler than having to go from HW to OS in a single driver ;-D19-Nov-09 14:34
334Maximbut its a compiler which can be easily embeded into any application.19-Nov-09 14:32
333Maximllvm is a compiler. its not an OS service.19-Nov-09 14:32
332Pekrbut where is LLVM preinstalled? What is the advantage in having R3 LLVM backend, if I can't find LLVM on my Vista machine? :-)19-Nov-09 14:30
331Maximit would be nice for R3 to support LLVM natively..... brian?19-Nov-09 14:27
330GeomolHeh, my test was about R2 and R3 performance, not to test how fast (or slow) one of my computers are. I could have run the code on my multi-GHz intel box.18-Nov-09 12:51
329RobertMacBookPro, 3.06GHz, Wndows in Parallels 5 VM18-Nov-09 8:10
328RobertTake this:

>> x: now/time a: 1. b: 2. loop 10000000 [a + b * a / b] now/time - x == 0:00:03

18-Nov-09 8:10
327shadwolfgemol if you want i can sell you minutes of use of on my computer :P18-Nov-09 1:10
326shadwolfit's R2 on my brand new Intel Core i5 750 / 4go DDR3 1333 Mhz with UD3 memory card18-Nov-09 1:09

>> x: now/time a: 1. b: 2. loop 10000000 [a + b * a / b] now/time - x == 0:00:03 Take that baby

18-Nov-09 1:08
324GrahamIf you used basic .. you only needed the first couple of chars anyway15-Nov-09 1:52
323MaximI meant all languages... AFAIK asians also use language ;-)15-Nov-09 1:50
322MaximGeo, I did the EXACT same thing... I had ALL of language E mapped in the commodities with some control key being required for the few letter words to be converted to language E equivalent :-)

coding was like ctrl+i var=1 ctrl+t ctrl+p "value = 1" ctrl+e (if var=1 then print "value=1" endif :-)

15-Nov-09 1:48
321Graham3 letters like asm op codes?15-Nov-09 1:48
320GrahamMax, makes more sense to switch to mandarin as it is the language spoken by the most people15-Nov-09 1:40
319GeomolI remember writing a program many years ago on my Amiga, that would change the input to what I choosed using a simple lookup table. I used it to write fast in e.g. IRC, where I would make a table with the 3 first letters of many english words. When I wrote 3 letters and pressed space, it would write the full word. Could be used to change things like !did to didn't. The good thing with the Amiga was, I connected to the console device (or what it was called), so the program worked everwhere with all other programs using the OS. Could also be used to e.g. program fast using shortcuts for command words.15-Nov-09 1:26
318Maximhehe15-Nov-09 1:20
317Reichartd;accordus15-Nov-09 1:19
316Maximto me, latin is to language what math is to physics. logic, order and structure... applied to chaos and randomness :-)15-Nov-09 1:15
315Maximwe should all dump all languages and just learn latin... stop the language madness ;-)15-Nov-09 1:14
314Reichart...I have considered moving to "!did" as in "NOT DID" to fix that problem. I really hate that polar words are not MORE different. For example even better than !did would be "did" and pop" for example. Where "pop" is the negative of "did".15-Nov-09 1:07
313MaximI have the Reichart chat disorder... In my case, I litterally see and read the word in my mind... not on the screen... so when I post, I often don't even realize words are missing or totally wrong... ;-)14-Nov-09 21:19
312Maxim;-)14-Nov-09 21:17
311BrianH"did=didn't" - LOL, yeah, no chance for mis-comprehension :)14-Nov-09 21:17
310Maximdid=didn't14-Nov-09 21:15
309Maximat first I did understand what you meant, I started a reply and then realized that you where explaining what I meant by closed... so I further expanded hehehe... no chance for mis-comprehension now ;-)14-Nov-09 21:15
308BrianHJust trying to head off another useless, off-topic source licensing flamewar :(14-Nov-09 21:10
307Maximsouce=source14-Nov-09 21:06
306Maximit seems the word "closed" is too closely coupled to souce in CS.... by "closed system" I do put the emphasis on "system" as in a chaotic system, like a complex frequency modulation patchbay or a closed-circuit video system where a monitor is in the view of the camera.14-Nov-09 21:06
305BrianHThis "closed system" has nothing to do with source availability, of course. As an example, value lookup from words associated with function! contexts is 28% slower that of object! contexts, just because of the addition of one instruction for stack indirection.14-Nov-09 20:52
304Maximthe host is a totally different beast. once a few of us have the host code and start hitting it with "applied" code, 2 things will happen IMHO:

* The core work will start to shift from "completing" R3 (architeture) to "finishing" it. (bugs, optimisations, docs, etc).

* R3's theoric usability (which is what pekr keeps refering too ;-) will be replaced by more and more "applied" usability, what you, I, and many others have been actively refering as "a working" version of R3.

14-Nov-09 20:41
303MaximGeomol, all the work on R3 was not about improving the runtime (host code)... as much as the language (the core dll).

improving the runtime is easier/faster cause decisions are either obvious or straightworward. work on the core is both tedious, highly philosophical, and complex. add one assembly instruction to functions evaluation and you've slowed functions down 50%, everything design Carl changes, basically cause side-effects else where, its a very organic process.

I see it like a closed system, where the slightest change causes feedback where you have to stop everything and start again, until the system is balanced and doesn't feedback. then you add another thing to the system.

14-Nov-09 20:30
302Ladislav"The money! datatype calculations are much slower, I guess that is the price of accuracy" - the money! datatype is implemented in software, while the decimal! datatype is implemented in hardware (FPU).14-Nov-09 20:16
301GeomolThanks, Ladislav.14-Nov-09 19:43
300LadislavGeomol: the page is accurate (AFAIK), so the doc needs to be updated in accordance with that.14-Nov-09 19:01
299BrianHIn other words: You are right, the docs are wrong.14-Nov-09 15:22
298BrianHGeomol, the manual was converted from the Core 2.3 manual, and most of the pages still reflect that. For types where the semantics have changed, the manual pages usually aren't updated until the semantic changes are finalized. This is not the case with money! yet, so the page hasn't been updated.14-Nov-09 15:21
297GiuseppeCPeterWood, I think that only a little step further is needed to have this. Developers want R3 to be used in REAL world scenario and do testing for passion; this is called "motivation". Even Carl admits the situation. When CGI support, VID, and extension will be finalized expect an huge boost into test and debugging.14-Nov-09 14:34
296PeterWoodGiuseppe: I think it would be better if more developers could test the R3 alphas and report bugs and issues rather than just wait.14-Nov-09 14:31
295PeterWoodI also ran the calculation test with R2 under Windows/XP using Virtual Box it took 4.368 seconds.

As native R2 on Mac OS X is faster than Windows R2 running under emulation, it looks as though the issue is the that the code is yet to be optimised.

14-Nov-09 14:28
294GiuseppeCKeep the faith !14-Nov-09 14:21
293GiuseppeCActually we are in the state where all developers should wait for the core to be completed. In beta stage they will be able to operate and cooperate to extend it.14-Nov-09 14:21
292PeterWoodI ran the calculation test under Windows/XP using VirtualBox. It took 5.009 seconds compared to 5.575825 seconds run natively under Mac OS X.14-Nov-09 14:21
291GiuseppeCREBOL3 has been rewritten from ground upp with high skills and few resources. This mean it needs time to be completed but it will be like a good wine.14-Nov-09 14:20
290GiuseppeCGeomol, sometime I felt frustrated by the long time REBOL3 took to be developed but now I see the light out from the tunnel and it is not the train running against us !14-Nov-09 14:19
289PeterWoodThe docs appear to be missing the warning that they still show the R2 docs.14-Nov-09 14:19
288GeomolThe documentation state, money! datatype uses standard IEEE floating point numbers. That can't be right. 14:13
287PeterWoodI not surprised that the Windows R3 Alphas run better than the Mac ones. Carl seems to develop for Windows and then ports to Mac and Linux in between "development phases". I think the more we report Mac bugs and issues in CureCode the more likely we are not to end up with a crippled R3 on Mac.14-Nov-09 14:10
286PeterWoodThe money! datatype calculations are much slower, I guess that is the price of accuracy:

>> a: $1.00 b: $2.00 dt [loop 10000000 [a + b * a / b]] == 0:00:15.957041

14-Nov-09 14:05
285HenrikI tested mine under VMWare, so that's a third environment.14-Nov-09 14:05
284GeomolIt's interesting, that the difference is large when running under OS X, and just a few percent when running Windows.14-Nov-09 14:04
283PeterWoodAn older MacBook Pro - 2.4Ghz Intel Core 2 Duo14-Nov-09 14:03
282GeomolThat might be the reason.14-Nov-09 14:02
281PeterWoodGeomol: "So we can expect R3 to be slower than R2, when it comes to calculations?"

No, I wouldn't expect R3 to have slower calculations. From what Carl has said, the R3 Alphas are not optimised for speed when compiled.

14-Nov-09 14:02
280GeomolWhat computer?14-Nov-09 14:01
279PeterWoodMy results R3 >> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]] == 0:00:05.575825

R2 >> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]] == 0:00:03.590101

14-Nov-09 13:59
278HenrikI don't think Carl wants to complicate R3 with fast maths that could be done smaller and faster as a C extension anyway.14-Nov-09 12:33
277Henrikyes14-Nov-09 12:32
276Geomolthe *way* to go14-Nov-09 12:32
275Henrik"we can expect" - no, I think we can expect a reasonable explanation to the slowdown and possibly a fix, when we get to that point.14-Nov-09 12:31
274GeomolYes, the say to go with heavy calculations is probably to get some C code written somehow, and then just use REBOL as the control program.14-Nov-09 12:31
273GeomolI got same result with latest PPC version of R3, 27 seconds. So we can expect R3 to be slower than R2, when it comes to calculations? hm14-Nov-09 12:30
272HenrikBut don't forget that extensions are precisely for such cases and R3 is way ahead of R2 here.14-Nov-09 12:30
271HenrikThere might be some math changes that BrianH knows way more about than me.14-Nov-09 12:30
270HenrikIt takes 55 seconds in R2 and 64 seconds in R3 here.14-Nov-09 12:29
269GeomolSeems like there's a newer version, than what I have installed. I'll try the newer one...14-Nov-09 12:28
268GeomolYou maybe forgot? :-) 12:27
267HenrikI didn't know there was a PPC version of R3.14-Nov-09 12:25
266GeomolI tested on an iBook. It might be different results under Windows!?14-Nov-09 12:25
265Geomola: 1. b: 2. dt [loop 10000000 [a + b * a / b]]14-Nov-09 12:24
264HenrikPlease post an example.14-Nov-09 12:23
263HenrikThe key is that if we want real speed, we can do it in C now.14-Nov-09 12:23
262GeomolI made a quick test to compare calc performance between R2 and R3. A 10'000'000 loop of some simple + * and /. It took around 17 seconds using R2, and 27 seconds using R3. If this is not changing, then I will probably continue to use R2 more than R3.14-Nov-09 12:23
261HenrikIf it's math heavy it will probably be around the same. If you use graphics, the better scalability of having many GOBs will help speed up certain operations. DRAW is currently around the same speed. If you use it as a C extension, then you will of course get C speeds. There are a few tricks in R3 to reduce the need for copying as well as some functions that have gone from mezzanine to native.14-Nov-09 12:23
260GeomolHenrik, you've used R3 more than I have, I think. Do you remember my work on FITS files in the spring from my visit to the telescopes at Tenerife? I made images from the 16MB FITS files using R2. It took 1-2 minutes to compute one file, where it takes less than a second if using C. How do you think, R3 perform compared to R2, when it comes to brute force calculations?14-Nov-09 12:16
259HenrikI said a looong time ago that we would, when R3 reaches beta, require a much larger number of developers to move forward. When extensions and host are properly released, this will still be the case.14-Nov-09 12:07
258GeomolFair enough.14-Nov-09 12:05
257HenrikI think that trying to get R2 View working properly under OSX will take longer than reaching the same goal for R3. I don't think there is much we can do in terms of speeding either R2 or R3 development up, so it's simply a matter of waiting until it's ready with the number of developers available to us. I don't want to disturb R3 development with too much interference from R2.14-Nov-09 12:03
256GeomolI'm trying to answer the question from Pekr: "why is R2 more interesting to you? I can't somehow understand it"14-Nov-09 12:03
255GeomolNo, you misunderstand. I hope and expect R3 to be able to do that some day. I just look at the facts: The project has been gong on for 4 years since 2005. Where it is now. When I can expect it to be in a condition, where I would begin to use it for real. (I've learnt to have very small expectations.)14-Nov-09 11:59
254HenrikGeomol, it sounds like you expect that R3 will never be able to do that. Why this attitude?14-Nov-09 11:54
253GeomolIt would be good, if you are right.

As an example of my use of R2, and where I can't use R3, look at this image:

I'm working on my bachelor project in astronomy at the university. I'm going to make a simulation of comets at the Late Heavy Bombartment some 3.9 bio. years ago to test a theory, that the water on Earth came from those comets. A part of my work is to study earlier simulaitons of 10'038 comets made by others. I would like to see, how the distribution of their initial situation looked, so I made a little REBOL script, that plotted the 10'038 comets and the orbits of the planets, Jupiter, Saturn, Uranus and Neptun. The image is showing this. It took me very little time to write the script in R2, and I can use the result.

Can you see, I can't use R3 for such things?

14-Nov-09 11:48
252PekrGeomol - wait half a year, and you might get even View/VID in R3. Core 3.0 is close.14-Nov-09 7:53
251PekrGeomol - you are completly off. I would not expect reaction like yours from person like you. Calling R3 dev. effort a hobby project? Where do you live, man? On a different planet? Sorry for being picky, but R2 dev. effort, compared to what we achieved with R3, is a complete joke, yet you call R3 being a hobby project?14-Nov-09 7:52
250GiuseppeCGeomol, last year I have written the same thing but this year a lot has happened. Once alpha i finalized and VID is complete expect a boost into the development. Also I suppose REBOL is short of money and programmers so they cannot speed up the project.13-Nov-09 15:13
249amacleodR3 is Alpha! A little unfair to call it a hobby project..13-Nov-09 13:56
248HenrikGeomol, I wouldn't expect any further development on lowlevel R2 View.13-Nov-09 13:52
247GeomolI have a huge graphical application written in R2 (Canvas RPaint, close to 13'000 lines of code), that I can't get released because of host problems and differences in REBOL between OSs. I do much of my development under OS X, and I have lots of utilities and applications written in R2, that suffer from problems in REBOL/View, that I might be able to solve, if the host code was released. I have tried to look into the graphical part of R3, but I can't see, how I'm able to convert my code to R3.

(I'm sorry to say so, but R3 to me looks like a hobby project, not a serious business projekt.)

13-Nov-09 13:47
246PekrI think that initially it will be released to only handset of developers, and after two or three weeks (my estimate), maybe others will be added too ...13-Nov-09 11:42
245PekrGeomol - host release plan can be found here - 11:41
244PekrI doubt you will see R2 source release anytime soon. R2 is monolithic in design, who knows how it is (or is not) internally separated. R3 was the answer to R2 inefficiency in that regard, so if you ask for R2 to have such a feature, you ask for R3 in fact :-)13-Nov-09 11:40
243PekrGeomol - why is R2 more interesting to you? I can't somehow understand it :-) There is many areas R3 already surpasses R2, is more precisely defined and consistent. Time to move to R3 really soon imo ...13-Nov-09 11:39
242HenrikThe host code release is going to be limited to 2-3 devs at first to weed out bugs.13-Nov-09 10:38
241GeomolIs this actually going to be released? And could we hope, the same thing would happen to R2, which is more interesting (to me at least).13-Nov-09 10:34
240PekrHost code works now - Carl reported he once again succesfully separated host from Core ....13-Nov-09 6:32
239shadwolfmain problem in ssl is the certificate no ?10-Nov-09 1:16
238shadwolfi'm more interrested in developping in rebol than any languages ... just the idea to go back to C programing world annoys me so much .... CArl is guilty with rebol he ruined my mood to code in anything else ....10-Nov-09 1:00
237shadwolfand they have pretty good ideas in the different area i'm sure they will rock VID10-Nov-09 0:58
236shadwolfbut yea maxim cyphre, gabriele, steeve, and any other people than me would feet the task10-Nov-09 0:57
235shadwolfi vote for GUI team ! And don't count on me to be part of it i'm just an idiot unable to understand my own source codes so the source codes from others .... too much a challenge10-Nov-09 0:56
234PekrI prefer View engine to be adressed first, definitely. More of Max stuff inside, more of Draw flexibility, caching, etc. .... then VID ...8-Nov-09 12:37
233GiuseppeCHenrik, you and the other people mentioned have great skills but I see sometime that everyone is moving creating his one version of something. Once the alpha stage ends and carl will define the roots of the new VID a group of high competent developers could cooperate and create the final product quickly and professionally.8-Nov-09 11:13
232Henrikyes, that makes more sense :-)7-Nov-09 22:49
231GiuseppeC*fixes7-Nov-09 22:37
230GiuseppeCI didn't want to say: "in place of Carl" but "together with Carl" once the low level GFX dixes are complete.7-Nov-09 22:36
229PekrGiuseppe - just don't worry :-) Look at the document Carl posted regarding host code release - there are several phases and Cyphre is definitely involved. I hope we cooperate for good ...7-Nov-09 15:46
228Henrik(I would still like to see Gabriele's MakeGOB dialect come to life. It can be very useful.)7-Nov-09 11:14
227HenrikOur main goal would be to build the official GUI for R3, which Carl is forming from scratch. Right now it would be a bit foolish to go build our own UI to immediately go into competition with VID 3.4. It would be double work.7-Nov-09 10:54
226GiuseppeCJust a question regarding GUI: We have GURUs like Henrik, Ashley, Cypre, Maxim. II have read that host source is being released to Maxim and Cypre. Why don't you build a GUI Team made of all those GUYs to push forward the developement ? I think they will make something explosive ! Also Gabriele has experiences because he build a prototype VID 3.4.7-Nov-09 9:04
225PekrTasking is there already :-)5-Nov-09 9:32
224PekrWe need to add it to the priority list ;-)5-Nov-09 9:32
223BrianHWrong group: We need to add it to R3 :)5-Nov-09 9:26
222Maximbut there is some of that built in to R2 already... which is why I say its *possible* to do in R2 as a server, the SSL code already in R2 would just have to be adapted to act as the server side of the handshake/transfer.5-Nov-09 8:52
221BrianHSSL is what you need. HTTPS would happen as a side effect.5-Nov-09 8:49
220MaximCarl once admitted that is was possible but not "enabled". AFAIK, he never told anyone the trick. maybe its unstable and didn't want to put time on it.

theoretically, one could build an https server protocol in R2... the encryption algorithms are all there AFAIK in /pro licenses. its just knowing the handshaking protocols and all that... I look briefly at the RFC once and its not "obvious" to implement... at least not for the bg I have.

5-Nov-09 8:39
219Pekralso server https would be nice - that one was not possible even with R2 https - I mean - you could not open open https://:4435-Nov-09 8:30
218Maximyes https should be on the list... as a separate scheme, or a config of the http scheme as it was on R25-Nov-09 8:26
217PekrI think I might rename my nick to - "watchdog" :-)5-Nov-09 8:25
216PekrSo, do we add https to the list? No matter if it gets adressed, it should be there imo. We somehow magically missed on that feature thru the whole development process. I never seen any blog, etc., which would even mention it ....5-Nov-09 8:25
215Maxim(gzip)5-Nov-09 1:56
214Maximeven for things like zlib.5-Nov-09 1:56
213MaximBSD or MIT... yes that is exactly what I proposed... it it VERY well coded and exceptionally small the whole putty app is in fact smaller than rebol.exe IIRC :-)

it has a LOT of goodies beyond a full SSH2 encryption set and EVERYTHING is stand-alone it relies on no external dll or libs.

5-Nov-09 1:56
212BrianHWhat's Putty's license? If license compatible we may be able to borrow its SSL code.5-Nov-09 1:52
211PekrHmm - interesting note in http blog comment section - what abot https? We never touched that area. Or maybe once, when Max suggested to look for Putty code. We need https surely too ....5-Nov-09 1:37
210PekrBtw - for future, to speed up some developments, I propose the bounty system - .... we would just need to define few rules, e.g.:

- the ability to merge bounties - the ability to predefine possible implementator - not everybody's code can be realistically accepted, etc.

I think that that way we can speed up some developments too ...

3-Nov-09 19:15
209CarlHi Robert, yes, it is indeed interesting "where the time goes".3-Nov-09 18:11
208RobertNice overview. Especially how long it took you. Give some "benchmark" on productivity.3-Nov-09 18:10
207CarlThe main change is to move HOST Source to a higher priority.3-Nov-09 18:10
206CarlYes, project doc updated. But, some priority changes are happening.3-Nov-09 18:09
205PekrBrianH: I think that everybody here understands, that we aim for 3.0 Core release. But even that one needs to be feautre complete. I would really like, if Tasking for e.g. would be there, because it CAN influence some modules, mezzanines or even natives. This is fundamental feature to have imo, and some devs (Doc - Cheyenne) are waiting for it. Then add back console. CGI under Windows was solved, Netwokring protocols are going to be adressed hopefully soon too :-)3-Nov-09 18:04
204PekrDid not know this doc got updated :-) 18:02
203BrianHThis means that we won't be putting off the R3 beta until we reach feature parity with R2. In many ways we have already surpassed R2, but there will be some things missing in this round (VID). If you need those features, keep using R2 for that portion of your project. The new GUI won't be compatible with the old ones anyways, so you might not want to delay starting migration because you may want to rewrite your GUI later.3-Nov-09 18:02
202BrianHREBOL 2 will still be here, and despite what some people have been saying it hasn't been abandoned. We have been focusing on R3 lately, but there will be new R2 releases to come. Migrating to R3 won't be an all-or-nothing affair. Gradual migration and mixed projects may be the norm for the short term. We don't want to block our users from uusing the killer features of R3 just because it doesn't do everything R2 does yet.3-Nov-09 17:56
201PekrInfrastructure first, please. That means - as much complete Core concept-wise, as possible - Tasking, enhanced extensions, Console for Windows, parallel work on View engine, so that 3.1 can come 3-5 month after 3.0, including initial VID3 release, sound.3-Nov-09 17:55
200BrianHIt is triage time, my friends. We are heading to beta, so we need to seriously consider what it practical to do quickly, and what needs be put off for a bit. REBOL is going to continue to have reasonably frequent updates - no more waiting years for the next release - so you don't have to act like your favorite proposed feature will never arrive if it doesn't make 3.0. We need to figure out what we need to make a useful beta.3-Nov-09 17:49
199BrianHBack to discussion of priorities, we shouldn't delay release because of those missing operations.3-Nov-09 17:43
198BrianHREVERSE, LIMIT and OF (but renamed I hope) are still on the todo list, and I really want all of those. My biggest pie-in-the-sky requests have been done though (with the exception of USE, which I have a workaround for).3-Nov-09 17:41
197GiuseppeCI think so. Carl won't open PARSE rebol code again once it reached this stage.3-Nov-09 15:42
196PekrREVERSE, OF - those are probably left fro 3.1 or later, because they are more difficult to implement. We should not thing about R3 development being stopped by reaching 3.0 release :-)3-Nov-09 12:45
195GiuseppeCHowevere PARSE is still not complete: REVERS is the only thing I miss. However, If we must judge, 95% of work on PARSE is done and only 5% is missing.3-Nov-09 12:29
194GiuseppeCNice to read you working on the host code together with Carl. Hope in a couple of years I'll be ablet to do this too :-) You are a good group.3-Nov-09 12:28
193PekrWonder where Peta is, though ....3-Nov-09 11:21
192PekrIs anyone still using Perl? :-) In the world of PHP, Python, Ruby hype? :-)3-Nov-09 11:20
191BrianHWe owned general-purpose parsing until Perl 6 started catching up. We have surpassed them now though :)3-Nov-09 10:52
190BrianHSeriously, we owe a lot to Peta. PARSE is much better because of Peta's work. A bit of a drive-by though: Came, argued well and helpfully, then disappeared. I look forward to the next time Peta shows up :)3-Nov-09 10:27
189BrianHThanks :D3-Nov-09 9:27
188Ashley+13-Nov-09 5:18
187PaulThanks Brian.3-Nov-09 4:36
186PaulI agreee Maxim. I don't always agree with BrianH on my issues but when it comes to Parse, I have been dead on with his ideas.3-Nov-09 4:36
185Maximand yes, Brian has put a lot of his time into R3 for free. He has been pushing and helping Carl into doing a lot of things which are now part of R3. He deserves our gratitude. h might have shaven a full year off of R3's implementation just by himself.3-Nov-09 4:33
184PaulThanks Maxim. I shall.3-Nov-09 4:31
183PaulI agree Maxim but now REBOL is far superior on the playing field.3-Nov-09 4:31
182Maximthere is such a reward, vote for him in the user.r group ... right here in altme :-)3-Nov-09 4:31
181PaulI know that me and Brian don't always see eye to eye but I'm an honest person where Christ has a say and I am humbled to acknowledge that Brian is instrumental in some of the greatest achievements of REBOL to date and see him as the REBOLer of the YEAR!!!!! if there were such a reward!3-Nov-09 4:30
180Maximwhen rebol came out it was hands down the best parser implementation out there... 10 years later the rest of the industry is catching up to it. We've pushed it a little further again.3-Nov-09 4:30
179PaulBefore we had what was very promising but the talent behind people like BrianH made Parse what it is now! Cheers to BrianH for his contributions - it is truely selfless.3-Nov-09 4:28
178PaulWell I would say until now we didn't. I believe Parse is now the most awesome thing in the programming world. Really I challenge our opponents to step forward with their product. What is greater? We dominate!!!!!!3-Nov-09 4:27
177MaximI'd say we always owned this corner ;-)3-Nov-09 4:24
176PaulWe finally own a corner!3-Nov-09 4:15
175PaulNow is the TIME!!!!!!3-Nov-09 4:15
174PaulYeah I know many people here think I hate REBOL - but truth is I love REBOL more than most of you and I want REBOL DOMINATION!!!!!3-Nov-09 4:15
173PaulNow is THE TIME!!!!!! .... for REBOL to claim the king of PARSE!!!!! this is where all REBOL marketing needs to focus IMMEDIATELY!!!!3-Nov-09 4:14
172BrianHShared write-protected structures too, afaict.3-Nov-09 2:57
171PekrNote: As Carl said for tasking - "the model is: threaded CPU, shared memory, shared symbol space, shared system function space, separate evaluation stacks, separate user contexts.""3-Nov-09 2:56
170Maximdevices could also be used for things like IPC or callbacks. so we could test out different ways to improve multi-threading in rebol before commiting to a specific method.3-Nov-09 2:55
169ReichartSolve the annoying hardware issues and connection issues, even proving it with examples, and then Carl can just intigrate...3-Nov-09 2:53
168Maximyep... the grunt work is where Carl can use our help.3-Nov-09 2:53
167ReichartTrue.3-Nov-09 2:53
166BrianHIf Carl is needed to really implement devices well, at least we can help by getting the almost-well implementations done, so all Carl has to do is tweak and merge. We can do a lot of research...3-Nov-09 2:52
165Maximif not, he'll point me in the right direction. then, when I get to vectors... the chance that I get it wrong will be smaller, but we have to start somewhere. We actually have to start doing it and stop just talking about it. :-P3-Nov-09 2:49
164Maximas a concrete example, if its possible for me to add image! support in Extensions right now (code, test, examples, documentation).... I will, and if its done properly, Carl will just be happy to sign off on it.3-Nov-09 2:48
163Maximobviously. Never said it differently. :-)3-Nov-09 2:46
162PekrExactly - we should be sure, that the design aspect is acceptable for Carl, in order to be accepted as a default part of the distro. The last thing we need that in such an initial stage, we will end-up with one host layer per one developer ;-)3-Nov-09 2:45
161MaximIf a few of us take up the task of managing all of the extensions/device interface code, that means Carl can work on other things. Carl has already given us a reference on his idea of how to integrate native code into R3. I wouldn't have done it any differently, honestly.

in any case, we will discuss it with Carl before commiting to any time to implementing it.

3-Nov-09 2:44
160Pekrshoul = show3-Nov-09 2:44
159Pekryes, I understand ... for later, maybe. But as for initial release, I would prefer Carl to implement (in regards to extensions) what's on a priority list. Believe me - if you shoul Carl, that maybe one day we have some ideas here or there, we will not get it for 3.0, as Carl will move onto other things.3-Nov-09 2:44
158Maximthe case is to have a core group of people improving the host in parralel.3-Nov-09 2:41
157MaximCarl will say no if he doesn't like it.

but do you really think that people which are going to be actively helping out in adding this type of code to the host to stray far from any ideals Carl may have?

3-Nov-09 2:39
156PekrIt is a language author call imo ...3-Nov-09 2:38
155PekrI don't like point 2) - I think that Carl knows best, how to add integration of Devices, eventual callbacks, images, etc. - simply the requested stuff. We (the community) should use extensions, we should not try to develop its API.3-Nov-09 2:37
154MaximJust giving a little report about a very interesting chat I had with Carl:

- Host code package is in the works... given priority. My impression is that Carl is really wanting for this to happen. If any of you feel you can actually participate and do real tests and work, now is the time to raise your voice. - Devices and the Extensions dll code are part of the host code. Thus, by extrapolation... We (i.e. Not Carl) could work on a model of Device extensions and propose it to Carl, if anyone (or group) wants to put the effort. obviously using the current Extensions as the reference...

- As it stands now, adding Native Datatypes is complex outside of the rebol core (ex: in host code) because of a few issues (GC integration being a major one).

- Carl isn't against the idea of finding a way to add Native (binary) user datatype but it most probably will have to wait a bit until Carl and Host developers find a way to make it simple and bug free. a possible idea is to bave a special extension model which acts as a datatype marshaller, with defined commands as datatype actions (aka accessors in other languages).

- Talked a little bit about threads, but nothing really specific to say about it... I'll need to try it in practice so I can ask relevant questions.

3-Nov-09 2:32
153BrianHPekr, command! functions will be used in dialects too. That is why the name was chosen.3-Nov-09 2:22
152Pekrjust a note - COMMAND. I was thinking lately, if the word is not too good to be used for extensions? Commands fit dialects. I thought that we could use ROUTINE in Extensions. But I know that it might be late for the change, or that I have maybe shifted understanding of what "command" word actually means ...3-Nov-09 2:17
151PekrCarl - have I said anything about difficulcy of getting source via R3 Chat? What I told is - we should not worry about much of the input, because even nowadays, not many ppl is using R3 Chat alone, not to mention getting sources via R3 Chat.3-Nov-09 1:45
150CarlGot to go... but I'll work on a core-only host package for tonight. That's a good way to sync up, because the whole thing is simpler to make and link.3-Nov-09 0:24
149Maximbe sure that the moment I get some form of host code or plan I'll react to it ASAP. This is the main "holding back" of R3 right now IMHO.3-Nov-09 0:19
148CarlAnyway, I'll put together a more detailed plan and get it to you. I want this to go quickly, but not waste any of our time.3-Nov-09 0:17
147CarlThat's a big topic. One we should move elsewhere, because it's likely to be many pages long.3-Nov-09 0:16
146Maxim(from extentions)3-Nov-09 0:14
145Maximdo we have some access to R3 funcs into Extensions?3-Nov-09 0:14
144CarlI want to migrate the graphics dialects (parsed via DELECT) into COMMANDS (yes, like in extensions).3-Nov-09 0:13
143Maximinstalled... 226MB (seems to include a few extra tools like C# and VB3-Nov-09 0:12
142CarlA few days of smoothing it out... and we should be good to go. But note...3-Nov-09 0:12
141CarlThen, I'll probably just drop you a zip of everything for you to try it and tell me what problems pop up.3-Nov-09 0:11
140CarlSo, the plan is to try go get the build mechanism setup again for the host development method.3-Nov-09 0:11
139Maximhad dun with unicode I guess ;-)3-Nov-09 0:10
138CarlWhat size is that? C++ S.E.3-Nov-09 0:10
137Maximhehe3-Nov-09 0:09
136CarlAh, ok... I build on the Mac-Mini here as well... because it by far shows me more coding errors than anything else... yep, the big endian smacks hard.3-Nov-09 0:09
135MaximI use visual C++ studio express. (free and simple)3-Nov-09 0:08
134Maximbut my mac is not setup for C coding ... (yet)3-Nov-09 0:07
133Maximyep. I also have a mac-mini now, so can also do some test on that.3-Nov-09 0:07
132CarlSo, here's a rough game plan...3-Nov-09 0:07
131CarlSo, Maxim, what's your main Dev system, is it Win32?3-Nov-09 0:06
130CarlYes, I have tortoise, but I don't use it much... because it's not that practical for work flow.3-Nov-09 0:05
129CarlWell, anyway, that's not the blocking factor.3-Nov-09 0:04
128Maximfor example, with tortoise, its integrated directly inside the file explorer :-)3-Nov-09 0:04
127Maximcvs is hell, but svn is really simple, at least on windows it is.3-Nov-09 0:03
126CarlBut the reason I use DevBase (R3 Chat) is because it has accept/deny recordkeeping.3-Nov-09 0:03
125Carlsimple and svn cannot be used in the same sentence, if I recall correctly.3-Nov-09 0:02
124Maximyou could just setup a simple svn for it... its really simple to setup, and we can all easily participate and share our stuff, even if working on the same files.3-Nov-09 0:02
123CarlBTW, I *always* tell new users... "do not use FOR" unless absolutely necessary.3-Nov-09 0:02
122CarlAnyhow... the blame for the Host is not on Cypre or anyone other than me.3-Nov-09 0:01
121Maximah... that's why :-)3-Nov-09 0:01
120CarlMaxim: native.3-Nov-09 0:01
119CarlPekr, so R3 Chat is difficult to get source code? You can't be serious. >> 26 .../Mezzaines >> get * --- Note: wrote file: work/r3/mezzanines/mezz-banner.r --- Note: wrote file: work/r3/mezzanines/mezz-control.r --- Note: wrote file: work/r3/mezzanines/mezz-debug.r ...3-Nov-09 0:00
118Maximis it still a mezz in R3?2-Nov-09 23:58
117CarlBTW... I was looking at your timings... puzzled by FOR times, I ran it in A94: >> dt [loop 800 [for i 1 1000 1 []]] == 0:00:00.0152-Nov-09 23:57
116Maximevery other time you've been here, I was off line for a one or two hour period... and everytime you're not here, I'm there during those hours... hehehe2-Nov-09 23:57
115CarlHello Maxim. Wow.2-Nov-09 23:57
114Maximwow... carl and I here at the SAME time ;-)2-Nov-09 23:56
113CarlYes... I agree... it is my fault!2-Nov-09 23:55
112PekrI second BrianH's opinion - please release to the first limited group of Devs, to prevent possible initial chaos. As for me - I think that we CAN manage the situation, even if you would release it publicly. Not many ppl use R3 Chat do download sources nowadays. I think that if you set some coordinator or two, e.g. BrianH, Henrik, Maxim - whoever who will accept the role, then we will be fine and even other ppl can study the code and try some things for themselves ...2-Nov-09 15:45
111BrianHCarl, listen to the chorus: Release some source, even if it is a limited release to the interested-and-qualified-helpers. You need help :(1-Nov-09 20:09
110CyphreCarl: Couldn't more agree with Gabriele here. If you update the Host codebase so it is possible to compile latest R3 builds...things can start move on again especially in the upcoming days.31-Oct-09 17:08
109PekrCarl: I have the same feedback from Cyphre - he was mainly waiting for the "Go" and synced sources ...31-Oct-09 13:07
108GabrieleCarl: "Cyphre was in charge of all graphics. But, he vanished into the Qtask black hole a year ago." More precisely, you stopped updating the host code on CVS, and me and him stopped having the ability to do anything useful on that front in the little time we had available.31-Oct-09 10:46
107Maximdon't worry, I want stuff to be simple to USE... its the behind the scenes which is complex ;-)31-Oct-09 6:43
106btiffinFrom the sidelines, I hope this bears fruit Maxim (and Carl). Very cool.

One favour to ask. Max, if you get hold of our low levels ... be gentle ... try and factor some of it down so the 2 dimensional 4 digit brain types still have a chance to decode some of that whiz bang almost too far out of the box stuff I suspect you may have brewing. :)

31-Oct-09 6:38
105MaximCarl, I posted messages to you privately on R3 chat... in case you didn't see them.31-Oct-09 5:19
104Maximtrue, I'll go there and see if there's more news for me.31-Oct-09 0:27
103GrahamQuicker to talk to Carl on r3 chat31-Oct-09 0:27
102GrahamJust hang around online for the next 24 hours Max31-Oct-09 0:01
101Maximdarn, I go away a few hours and Carl pops in.... basically offering what I've been dreaming for the last Decade! I would really like to participate in the host code, right now, I'm basically giving myself a very in-depth course in applied 3D graphics and I won't lie in saying I'd rather do it R3 if I would be sure that I won't run into an unknown and be stuck.

my comment wrt R3 being buggy, is not a comment on the quality of R3 itself, but the fact that many core things still change quite often. so code using R3, especially very hard to debug and complex code like 3d arithmetics can become a nightware with the slightest little change.

30-Oct-09 23:47
100OldesCyphre told me that he is waiting for actual sources. So maybe giving him the latest host source would be a good start.30-Oct-09 22:32
99CarlI'm sure he would really like the candy.30-Oct-09 20:52
98HenrikI think we should get a hold of Maxim and see what he says. If he gets free access to the candy store, he might change his mind. :-)30-Oct-09 20:51
97CarlWell, my main goal is to get parallel development on it. So, if things are needed on graphics for View, that can happen while work is done on other core items.30-Oct-09 20:44
96HenrikIf it helps to get the host code done first and then get someone to work on graphics, maybe that's a better idea. R3 is making great progress in other areas, which we don't want grinding to a halt.30-Oct-09 20:37
95CarlI don't want to release it to everyone yet, because it would consume all my time to deal with the feedback, changes, hacks, etc.30-Oct-09 20:34
94CarlWell, a "limited release" of the main host source is not entirely out of the question. Meaning, released to a small group.30-Oct-09 20:34
93HenrikAlthough I know he has some very particular features he wants to see in DRAW.30-Oct-09 20:31
92HenrikI think simply he hasn't considered if he would ever be put in charge of View.30-Oct-09 20:30
91Steevei'm interested too (cause i already made a partial svg converter for R3 ,see ) But i'm afraid i will be disconnected from rebol stuffs during comming weeks.30-Oct-09 20:30
90Henrik"cause its buggy, cause I've got no time for release "surprises" nor can I use all of the several MB of code I already have which works in R2. going to R3 is a big endeavor for people like me who have a lot of code to convert." - Maxim30-Oct-09 20:29
89Henrik"I can't risk working 2 weeks and hitting an issue which can't be solved because its an unfinished part of the host." - Maxim on R3 View30-Oct-09 20:28
88CarlBuggy?30-Oct-09 20:27
87HenrikR3 is too buggy for him, but I think he has not considered himself getting a chance to fix those bugs. If he has a chance, maybe he'll change his mind.30-Oct-09 20:26
86CarlIf he's so busy on 3D for R2, maybe he should jump to R3?30-Oct-09 20:24
85CarlI know Maxim likes OpenGL too.30-Oct-09 20:24
84HenrikYes, good candidate. He's working on !SCARE right now. Some 3D engine for R2.30-Oct-09 20:21

Return to Index Page