| # | User | Message | Date |
| 565 | Graham | Max lives in a world of his own ... and I don't know the address! | 9-Jul 1:51 |
| 564 | Sunanda | Max posted this to the mailing list about a month ago: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlFGXC | 8-Jul 22:21 |
| 563 | Mchean | any results? | 8-Jul 21:44 |
| 562 | Graham | and gmail chat | 19-Apr 7:44 |
| 561 | Tomc | I think you can still get his attention on the maillist | 19-Apr 7:43 |
| 560 | Josh | although it looks like he hasn't been on for a while | 17-Apr 16:08 |
| 559 | Josh | Maxim, you ever get some more of those demos worked up for liquid? | 17-Apr 16:05 |
| 558 | Maxim | basically going to use a HASH of liquid nodes (the nodes themselves being already connected) and just asking for cell values, based on what cells are visible within the scrollpane. | 5-Jun-07 16:43 |
| 557 | btiffin | :) | 5-Jun-07 16:42 |
| 556 | Maxim | (or until the GC starts caving in ;-) | 5-Jun-07 16:41 |
| 555 | Maxim | I've started a simple test... but will start over... the new version will handle as much cells as you have RAM :-) | 5-Jun-07 16:41 |
| 554 | btiffin | I'll pipe in...I've got a modified copy of nanosheets with scroll bars so it could support more cells for financials sheets for the Fire Deparment volunteers... | 5-Jun-07 16:10 |
| 553 | Maxim | hum... I'm thinking its going to be much easier to make a pico sheets ;-) | 5-Jun-07 10:59 |
| 552 | Maxim | (just started looking at nanosheets... must have a little fun) | 5-Jun-07 10:51 |
| 551 | Maxim | ok. can it be packaged as a library module ;-) I'd put it up on revault | 25-May-07 15:59 |
| 550 | Gregg | I'll mail it as well. Not on REBOL.org...just time, priorities, and lazyness. | 25-May-07 15:50 |
| 549 | Gregg | http://www.devx.com/opensource/Article/27454/0/page/1 http://www.devx.com/opensource/Article/27969 | 25-May-07 15:48 |
| 548 | Maxim | why is it not on rebol.org? | 25-May-07 15:47 |
| 547 | Maxim | can you mail it to me? does it depend on any particular version of view? | 25-May-07 15:47 |
| 546 | Gregg | I think the final nanosheets code went up with the DevX article. If not, I have it here. | 25-May-07 15:45 |
| 545 | Maxim | robert, If I start from scratch, it will be an n dimension spreadsheet with a scale of infinity in each of those dimensions (thus really limited by RAM, disk and REBOL types). why start it up with a limitiation which is actually very easy to design correctly for starters... especially with GLayout which would just adjust the views as they grow. | 25-May-07 15:26 |
| 544 | Maxim | mario, mind maps are very cool... I would like to make an optimised tool for quickly creating and organising mind maps in elixir but I can say that I hope others will join me in adding toolsets... its the whole point of elixir, an open, common framework of integrated and live tools. anything goes into anything, so you can do things like share data between, you graphics, mind map and project management... why not even use some of it to drive the GUI building for one of the panes... I mean, in the end, they are all being used for one goal. | 25-May-07 15:23 |
| 543 | Maxim | jean-francois, that would be an integral part of elixir :-) so wait for it to give you such capabilities within your whole work environment | 25-May-07 15:20 |
| 542 | Maxim | where Can I find nanosheets? | 25-May-07 15:19 |
| 541 | Maxim | perfect examples :-) I forgot about the spreadsheets yes, it would be pretty simple to wire up :-) | 25-May-07 15:18 |
| 540 | Gregg | It would probably be easy to plug liquid in to nanosheets. I'd like to see that too. The current evaluation order is fixed L->R-->Top->Bottom; with liquid you might be able to do away with that entirely, and let the evaluation drive things. | 25-May-07 15:15 |
| 539 | Pekr | you could use nano-sheets, no? :-) | 25-May-07 13:17 |
| 538 | Robert | If this works, I'm adding it into my app ;-) | 25-May-07 13:10 |
| 537 | Robert | Max, on of the best examples would be a Rebol based simple 20x20 Excel clone. Let people use Rebol code in the cells, and handle the reference handling via Liquid. It should be perfect DF applicable. | 25-May-07 13:10 |
| 536 | Mario | Ditto: http://fileforum.betanews.com/detail/ConceptDraw_MINDMAP_Professional_for_Mac_OS_X/1118155814/2 | 25-May-07 11:42 |
| 535 | Jean-François | Maxim, I don't know if this would be considered simpe, but here is a suggestion: http://www.bliner.com/projectmanagement.html | 24-May-07 23:36 |
| 534 | Maxim | although that is all very high level speak. at low level its still pretty much the same concept. | 24-May-07 17:29 |
| 533 | Maxim | cause in many times when IT changes you get unwanted results out of its interaction with other systems. | 24-May-07 17:28 |
| 532 | Maxim | you can figure out that out of 10 systems, one is actually contributing to most of the indirect unwanted outputs. | 24-May-07 17:27 |
| 531 | Maxim | and actually generate other data from it like diffs or comparison reports. :-) | 24-May-07 17:26 |
| 530 | Maxim | want text ports, just make a liquid which spues out text on the console... need that logged, just plug in another node which spues out stuff on disk as it comes in... but you don't even have to change anything in your systems... and can even easily connect your logger to other nodes, so you can track the flow of traffic, or the end effects some root events are having on the outputs of the system. sometimes its not obvious to see the real world relation of inputs and output... liquid allows you inspect all states at all points in time of you system's processing and compare it. | 24-May-07 17:25 |
| 529 | Maxim | so one (actually several) machines can be a controler and synchronise to others which can also locally change their states... and whatever they data can generate can be sent to any other machine, including the controlers... so you have ONE kernel to handle all aspects of your systems. and its dead easy... and would interface directly within any other liquified systems like liquid GL, elixir, globs, or eventually GLASS. | 24-May-07 17:21 |
| 528 | Maxim | obviously, the standard issues of machine redundancy will arise, but that is a good exercise for the later revisions of the system. | 24-May-07 17:18 |
| 527 | Maxim | basically a connection based TCP i/o interface to any liquid network. you define the ports, the protocol (on either end) and can then interface your Dataflow across machines :-) it would allow distributed processing without any understanding of such concepts. | 24-May-07 17:17 |
| 526 | Maxim | my next step for liquid (what I was working on During the devcon, but wasn't able to get done do to lack of sleep) was the creation of liquid net. | 24-May-07 17:16 |
| 525 | Maxim | and won't trigger other events. | 24-May-07 17:15 |
| 524 | Maxim | the nice thing is that you don't have to want to be aware of everything.. so whatever is not interesting will not cause *much* processing. | 24-May-07 17:14 |
| 523 | Maxim | which will be triggered whenever you want to be aware of things... | 24-May-07 17:14 |
| 522 | Maxim | but liquid would allow you to pregrogram any matter of "alerts" based on specific conditions, for example. | 24-May-07 17:13 |
| 521 | Maxim | yes that would be easy (figuratively speaking) now it obviously depends on the nature of your interfaces and what you track... | 24-May-07 17:13 |
| 520 | BrianH | Sorry if that was confusing. Most of my code has no user interface at all. It runs without intervention. Any monitoring or command interface is seperate. Most of my data points correspond to physical objects in the real world, and the code mostly tracks and directs these objects. | 24-May-07 17:12 |
| 519 | Maxim | I'd need a bit more explanation of what you mean by that. | 24-May-07 17:10 |
| 518 | Maxim | Brian asks, "Can you map nodes to physical world objects?" | 24-May-07 17:10 |
| 517 | Maxim | so, my answer to DideC, I guess, is: Give me ideas on simple demo applications I can build ! And I'll consider which one I do first. :-) I need and want this info to make the whole package more appealing and comprehensible. The current uber simple Sum example, just gives a glimpse of the engine's capabilities, not of its application. | 24-May-07 16:33 |
| 516 | Maxim | elixir already has that built-in to its values, so any gadget also inherit their "flawlessness" but its not something that jumps at you... its a subtle but oh so important detail. | 24-May-07 16:29 |
| 515 | Maxim | I think the best, simple illustration of liquid will be in making an unbreakable form example. | 24-May-07 16:28 |
| 514 | Maxim | I do want to convert rebolek's famous color picker into using liquid... one of the thing which will be made better is the fact that I can sample colours from mouse events much more often than actual refreshes occur, so that it should feel smoother. | 24-May-07 16:27 |
| 513 | Maxim | the real problem is also that dataflow usually improves larger systems. so small demos might not illustrate the particular merits of using liquid, unless you count in the subjective, bug free, nature of most DF systems. | 24-May-07 16:26 |
| 512 | Maxim | once revault is at least put to demo on line and I start getting feedback, I will turn to liquid fullblast... what I am really looking for are examples of simple apps which can be liquified. | 24-May-07 16:24 |
| 511 | Maxim | I have a pretty nifty parse-rule generating application which uses liquidGL but its far to complex to be used for understanding of anything. | 24-May-07 16:23 |
| 510 | Maxim | unfortunately, demo apps are still not available. One person using liquid is making a for profit dentist EMR and scheduling app. there is elixir, and there was the original liquified draw dialect example I had released just before the new year. | 24-May-07 16:22 |
| 509 | Maxim | elixir is a proof of concept generating application... I am still measuring how well the generalised use of Liquid in all aspects of an application equate to all of my claims, but so far, empiricaly... it seems to be keeping up the intended benefits. | 24-May-07 16:20 |
| 508 | Maxim | dideC: well, I'm am working towards that. I am keeping up the habit of working on one thing at a time and currently I'm hard at work on Revault. that being said... guess what are the first libs to be put online ;-) | 24-May-07 16:19 |
| 507 | Maxim | Hi doc, The version of liquid on line is not quite the latest (obviously)... but I'll check out your info... its possible that one was already fixed.... I fixed a few minor bugs since I last released. Mainly due to intense use within glob and elixir. | 24-May-07 16:18 |
| 506 | DideC | Hi Max, Do you have any demo apps using liquid ? Something simple, but usefull to help me (and others) understand how and when to use it. | 24-May-07 11:18 |
| 505 | Dockimbel | Hi Max, reading the %liquid.r source code from rebol.org, I've found a typo at line 948 : count plug/subordnates object! (i missing in "subordnates"). | 24-May-07 10:08 |
| 504 | Maxim | hum liquid is what 50 kb of 0% optimised code. DF its a data processing kernel, paradigm level feature.. quite different in scope. | 22-May-07 15:51 |
| 503 | Gabriele | eg, should pdf maker be built in? of course not! | 22-May-07 15:49 |
| 502 | Gabriele | if we had to put everything that is cool built in, rebol would be 10mb like many other languages. | 22-May-07 15:49 |
| 501 | Gabriele | full df, sure, but no reason to have it builtin. | 22-May-07 15:49 |
| 500 | Maxim | it wont remove what you propose... and in fact its not even more complex in use. | 22-May-07 15:48 |
| 499 | Maxim | but I know your POV. but you don't see how limited that becomes. we could have what you propose and ALSO have full DF. | 22-May-07 15:48 |
| 498 | Maxim | you see, if we had a dataflow datatype, we would not even need to talk about "do we add this to VID" people could just set values to attributes which are DF based. | 22-May-07 15:45 |
| 497 | Gabriele | liquid is small, but the functionality we needs comes free with my vid design, so you can't win ;) | 22-May-07 15:45 |
| 496 | Maxim | especially since its such a small kernel ! (not the current implementation, which has a few prototypical stuff left) | 22-May-07 15:45 |
| 495 | Maxim | ;-) | 22-May-07 15:44 |
| 494 | Maxim | cause you do not see its value if it where built in. | 22-May-07 15:43 |
| 493 | Gabriele | noone stops people from including liquid | 22-May-07 15:43 |
| 492 | Maxim | nope. | 22-May-07 15:43 |
| 491 | Maxim | its something the whole language should have. | 22-May-07 15:43 |
| 490 | Gabriele | we only need it for the gui - that's exactly my point | 22-May-07 15:43 |
| 489 | Maxim | dataflow has nothing to do with GUI. | 22-May-07 15:43 |
| 488 | Maxim | but you are only seeing all of this as a VID thing. | 22-May-07 15:42 |
| 487 | Gabriele | exactly, just an action, or to say it differently, just an event. | 22-May-07 15:41 |
| 486 | Maxim | that really is just like an action. | 22-May-07 15:41 |
| 485 | Maxim | (tested) | 22-May-07 15:40 |
| 484 | Maxim | that doesn't scale well. | 22-May-07 15:40 |
| 483 | Maxim | at a high level yes. but in reality, no. if you have some gadgets or other parts of dependent systems which do not "need" the value, it might not cause any refresh. | 22-May-07 15:40 |
| 482 | Gabriele | my decision is not to pull at all, if something changes the change is pushed to everything that needs to know. | 22-May-07 15:40 |
| 481 | Maxim | " does it pull x times a second?" that is up to you to decide, really. | 22-May-07 15:39 |
| 480 | Gabriele | that is push, isn't it? | 22-May-07 15:39 |
| 479 | Maxim | its also nice to know that your GUI is actually capable of reflecting data. not just gui. change the data: fill data value and don't even have to wonder IF and HOW any gadget should change. | 22-May-07 15:38 |
| 478 | Gabriele | when you move a slider that is attached to something, is that something that has to pull? does it pull x times a second? | 22-May-07 15:38 |
| 477 | Maxim | the only difference is that some (switcheable in real time, even set to a function) which will always want to refresh, when they are aware of data changes. | 22-May-07 15:38 |
| 476 | Maxim | nope, its all using the same core plug. so its really pull based. | 22-May-07 15:37 |
| 475 | Gabriele | max: liquidgl is push based, isn't it? so "lazy" does not count. | 22-May-07 15:36 |
| 474 | Maxim | and in fact, if we do add a measure of reflexivity to VID, we will just be redoing most of liquid, or run in the same issues, I had in my other prototypes, which led to this design. ;-) but we will not gain the advantage of having generic dataflow! | 22-May-07 15:36 |
| 473 | Maxim | The truth is, I do not have the reflex of using liquid for most of my coding, still, but actuall exposure and use, is forcing me to value its effect on my code. this is empiric use, not advocacy. If you could see just how easy it was for me to build fully bug-free AGG gadgets in so little time, you'd understand. its not about just sharing data between gadgets, its about allowing your code to know what's going on. | 22-May-07 15:35 |
| 472 | Maxim | I am as anxious as all of you and understand ALL of your qualms about using dataflow and liquid. *complexity? *speed? *scalability? *difference in programming model * .... | 22-May-07 15:31 |
| 471 | Maxim | I was able to write elixir in about 40-50 hours of time and the only bugs it has are within the parts of code which has no dataflow. everytime I trust liquid and switch part of the code to it, I end up forgetting about that part, because it gets to be so stable. | 22-May-07 15:29 |
| 470 | Maxim | liquid's strength lies in the fact that it is generic. we all write dataflow within our applications, without realising it. but we then recode each little system in its own isolated architecture. this means we just loose a lot of time. | 22-May-07 15:26 |
| 469 | Maxim | I have gone through 3 rewrites before hitting this sweetspot. other versions might have been simpler in a way, but left the system, non generic and unscalable in one of many different ways. | 22-May-07 15:22 |
| 468 | Maxim | the system in its current form is not meant to be easy to code (for maintenance reasons). I know many ways to change this, but before going to far, I had to have as stable an architecture as possible. | 22-May-07 15:21 |
| 467 | Maxim | Gabriele, liquid (dataflow) adds a level of stability to any project. the fact that its lazy pays off very well so far. | 22-May-07 15:19 |
| 466 | BrianH | Single process, no virtual memory - through other tricks, they managed to avoid needing it. Because of this the event broadcast, like everything else it did, ran by itself on the bare metal. Hence the speed. | 20-May-07 1:01 |
| 465 | BrianH | Because of this it was able to manage a full GUI and still be as fast as DOS. | 20-May-07 0:56 |
| 464 | BrianH | No multithreading on Oberon (back in the day - Active Oberon has it now). They managed multitasking through shared memory structures and other interesting tricks. | 19-May-07 23:51 |
| 463 | Gabriele | volker... oberon may be doing tricks, such as not really broadcasting to everything... so the fact that it is fast does not make the approach a good approach. | 19-May-07 17:20 |
| 462 | Gabriele | petr, yes and no. yes in the sense that events come from devices, no in the sense you mean (libevent). i don't see why we would need libevent or anything like that. | 19-May-07 17:17 |
| 461 | Volker | 100k instruction/event. | 19-May-07 16:42 |
| 460 | Volker | It works for the gui. I dont step into theory about slow, if i have a real life example which is fast :) about everything to everything, that would be in a bad case: each event to 100 receivers, 100 events/sec, 10k dispatches/sec. cpu can do 1 billion instructions. 10k instructions/event. most of them: i am interested? no. ~100. | 19-May-07 16:41 |
| 459 | Pekr | Gabriele - is there new event system in View? IIRC we were thinking along the lines of plugging some external library into rebol - libevent, liboop, etc. | 19-May-07 12:27 |
| 458 | Gabriele | also... we have network events, system events, you could have usb events and many more... do you broadcast everything to everything? when an event generates another event, is it broadcast to everything? it does not seem a great model to me... :) | 19-May-07 12:09 |
| 457 | Gabriele | eg. imagine if every face got every event. | 19-May-07 12:07 |
| 456 | Gabriele | that may mean that they were smart, it doesn't mean that broadcasting scales well. ;) | 19-May-07 12:07 |
| 455 | Volker | Gabriele, did i notice i used Oberon? :) Fastest thing i have seen on a P100. Maybe muchmore on Amiga could compete :) | 19-May-07 11:50 |
| 454 | Pekr | Gabriele - but, what I would not like to see is - to start with system, which is not flexible enough - e.g. old VID - you CAN'T add some things later, unless you count on them from the very beginning! Then docs appear, ppl start to produce scripts, and then we complain that we can't change it, because there is lots of dependency ;-) Please bear in mind, that NOW is the time for the change ... | 19-May-07 11:07 |
| 453 | Gabriele | we may not be able to emulate r2 faces in july... so no compatibility... but other than that it should be functional | 19-May-07 11:07 |
| 452 | Gabriele | the compositing engine is almost ready... so why not release it. | 19-May-07 11:06 |
| 451 | Pekr | I thought Core comes first (but more complete), then View ... | 19-May-07 11:06 |
| 450 | Pekr | Gabriele - that is still nice. I did NOT expect View to be released at all, so .... | 19-May-07 11:03 |
| 449 | Gabriele | volker: broadcasting to everything... do you think that scales well? | 19-May-07 10:37 |
| 448 | Gabriele | petr, we may not be able to deliver all of that for july (or maybe yes, depending on community help), but it's certainly planned and will happen | 19-May-07 10:32 |
| 447 | Pekr | Let's create new VID, which will be both easy to use from user perspective, yet easily extensible for developers. That means, that engine has to support those basic functionalities from the very beginning, otherwise we will be in the trap once again ... | 19-May-07 10:32 |
| 446 | Pekr | I think that VID is nice. Dialected aproach is the way to go, that is for sure. I would be OK, if VID would fix some things as - tabbing, cursor change, accelerator keys, visual focus representation to widgets, disabling/enabling (for business wide widgets), resizing, methods for drag & drop etc. Look e.g. at VID's feel - it was abstracted, that you have central storage of "feels", but was that abstraction used to any good by anyone? I like self-contained styles/widgets of rebgui better. | 19-May-07 10:30 |
| 445 | Gabriele | graham, i believe easier than using liquid ;) on the dialect level, you just use "attach" like max does in liquidgl. | 19-May-07 10:30 |
| 444 | Pekr | Well, if we interface to user via a dialect, then it is ok to me. The thing is - web is full of various frameworks. I read about them, about their ideas, and it is OK. The trouble is, that for the thing to be usable, you have to study, what the framework author though about, when he/she was creating a framework. And I fear, that way too much abstract framework will distract coders, as they will not understand, how to extend it, etc. | 19-May-07 10:27 |
| 443 | Volker | Later i moved to oberon. Oberon does not use explicit connections. Instead each event is broadcasted to everything. WHich may broadcast it to its inner parts. I found that to be easier and more flexible. | 19-May-07 9:14 |
| 442 | Volker | Just in Mozilla: Was reading rss in sage, opened bookmark-editor, moved bookmarks, sage was updated. i think liquid is for such things. also the wiring can be shown graphically. Have seen that with Visual Age did that long ago. If it is well done its not a bad idea. I still fear it will be hard to debug, since all this wiring is invisible. Or maybe: it was to easy to create for me. BAck in that days i found such connetion-stuff cool and created a lot spagethi. (was not using VA, that method worked with pure oops too^^) | 19-May-07 9:06 |
| 441 | Graham | Does it make it easier for ordinary programmers though? | 19-May-07 8:25 |
| 440 | Gabriele | i'm interested in examples where this would not work. (i think i can reproduce all examples i have seen from you so far, ie. sliders attached to fields and so on) | 19-May-07 8:11 |
| 439 | Gabriele | from the user pov, it looks like a network, but internally it is not. in particular, events don't need to be propagated (this avoids the cycle problem altogheter) | 19-May-07 8:10 |
| 438 | Gabriele | my conclusion is the same as nenad's... it's overkill :) i think i can do all that users need to do with just event handling. that is, recognizing that in the ui everything is about events. the system does not need a network, just direct "links" between elements (call them widgets, styles, etc). | 19-May-07 8:09 |
| 437 | Gabriele | max... i've been studying liquid and how it can be used (or not ;) in vid+ (or vid2 or vid3 or whatever we want to call it) | 19-May-07 8:07 |
| 436 | Maxim | ciao and thanks for the interest... any question you have, I'll be happy to answer. | 18-May-07 20:40 |
| 435 | Mario | See you | 18-May-07 20:39 |
| 434 | Maxim | hehe. | 18-May-07 20:39 |
| 433 | Mario | sue=use | 18-May-07 20:39 |
| 432 | Mario | I sue similar tricks as a teacher, maybe you made the right choice | 18-May-07 20:39 |
| 431 | Maxim | it used to be that I was scared the spec of liquid would change too much and I would run into support issues, but so far, its remained backwords compatible for the last year... and I have implemented VERY complex systems using it, so I am now confident its in a state of production approval. | 18-May-07 20:39 |
| 430 | Mario | I Agree, Maxim. I was thinkg the same thing whan I met the script...: "Maybe Maxim wanted me to understand the basics before I play with this new toy or I won't appreciate it" | 18-May-07 20:38 |
| 429 | Maxim | ok, well I have to log off, but I agree. The liquid part of my site, has a usefull simple tutorial, but it needs more advanced examples and stuf, and that's where I'm at now :-) | 18-May-07 20:37 |
| 428 | Mario | I think that samples are a must for such kind of stuff. VID, Draw, Services, rebcode and similar powerful things lost their momentum due to the lack of eaxamples imo | 18-May-07 20:37 |
| 427 | Maxim | when you see just the trick, you usually are clueless ;-) | 18-May-07 20:36 |
| 426 | Maxim | but then, its possible having done each step helped you understand the magic trick ;-) | 18-May-07 20:36 |
| 425 | Maxim | thanks, good idea :-) point taken | 18-May-07 20:35 |
| 424 | Maxim | and it seems, by a strange twist of faith, that I suddenly have A LOT more time on my hands... (I'll let you figure out why ;-) | 18-May-07 20:35 |
| 423 | Mario | A suggestion: put the working full script as a downloadable file (rebol.org or a link from liquid site) at the beginning of the page. I did the example step by step following the page and, at the endo of my tests I found the full script I colud copy and paste!!! | 18-May-07 20:34 |
| 422 | Maxim | and supporting people who use it. | 18-May-07 20:34 |
| 421 | Maxim | I am at a point where all my stuff basically works, I just need to start disseminating the information, spreading the word. | 18-May-07 20:34 |
| 420 | Maxim | I will be giving a lot more tutorials and examples, in the following weeks. | 18-May-07 20:33 |
| 419 | Maxim | cool, happy to know that people are starting to try out liquid. | 18-May-07 20:33 |
| 418 | Mario | I tried your examples on the site | 18-May-07 20:33 |
| 417 | Mario | I am really curios as I cannot come to Paris... Last DevCon was in my school so it was simpler to me to attend ;) | 18-May-07 20:32 |
| 416 | Maxim | all on rebol.org | 18-May-07 20:32 |
| 415 | Maxim | liquid is online. | 18-May-07 20:32 |
| 414 | Maxim | liquidGL next week. | 18-May-07 20:32 |
| 413 | Maxim | glayout yes. | 18-May-07 20:32 |
| 412 | Maxim | elixir no, in two weeks (beg june) | 18-May-07 20:32 |
| 411 | Maxim | but seeing people's real use cases helps me see where to put the time on whatever I do next, and your example shows me that I am dead on my priorities :-) | 18-May-07 20:31 |
| 410 | Mario | During the devCon I "saw" some GUI while you were presenting your programs, are those scripts available to the public? | 18-May-07 20:31 |
| 409 | Maxim | no problem, I'm happy to help. | 18-May-07 20:31 |
| 408 | Mario | Nevr mind, Maxim. Talking about this with you suggested me easier way to implement such services and this is an help too! | 18-May-07 20:30 |
| 407 | Maxim | plus I am working on getting a quick Revault demo site ASAP. | 18-May-07 20:30 |
| 406 | Maxim | if I had just a bit more time, I'd be glad to help, but comming back from the devcon has but a strain on my time (a lot of time to make up at work and at home) | 18-May-07 20:29 |
| 405 | Maxim | it should be possible to add an adaptor in order to plug a liquid system within a reb service, but thats a later stage. | 18-May-07 20:28 |
| 404 | Mario | I will try to use the liquid concepts adding attributes to the nodes and do a "classical" plugin for the proxy | 18-May-07 20:28 |
| 403 | Maxim | using encryption if you have those options in your license. | 18-May-07 20:27 |
| 402 | Maxim | it will be direct tcp intercommunication in between nodes. | 18-May-07 20:27 |
| 401 | Maxim | if elixir where ready for release, then, yes it would be a simple click and drag... but alas, its not there yet.. | 18-May-07 20:27 |
| 400 | Mario | haw should the net module work? ?services? | 18-May-07 20:26 |
| 399 | Maxim | hehe, right now... with the cgi in between, I don't think you'll get a lot more out of building it in liquid... | 18-May-07 20:26 |
| 398 | Maxim | but its nowhere near ready... I'm starting to look at the discrepancies of tcp/ip and liquid models. | 18-May-07 20:26 |
| 397 | Mario | I am wondering what to do: on one hand I'd really like to create a liquid application, on the other hand I must finish the program in a few days... | 18-May-07 20:26 |
| 396 | Maxim | I am at the point of making my liquid net module for liquid, which would alleviate the need for a cgi-based system in your setup. | 18-May-07 20:25 |
| 395 | Maxim | this is the purpose of the instigate function. | 18-May-07 20:25 |
| 394 | Maxim | actually, internally that is how liquid functions, it asks for state of dependencies. | 18-May-07 20:24 |
| 393 | Maxim | yes | 18-May-07 20:23 |
| 392 | Mario | The poll results should generate a data flow... | 18-May-07 20:23 |
| 391 | Mario | Can I poll a status update from the server each, let's say, 2 mins? | 18-May-07 20:23 |
| 390 | Maxim | or rather, of the other things it relates to. | 18-May-07 20:22 |
| 389 | Maxim | liquid can help you automate the process easily, but you still need to allow each thing, to be aware of itself. | 18-May-07 20:22 |
| 388 | Mario | I see... | 18-May-07 20:21 |
| 387 | Maxim | so unless you can listen to someone, you will never know. | 18-May-07 20:21 |
| 386 | Maxim | but now you add the concept that "another" computer changes your state... you have to be made aware of that change. | 18-May-07 20:21 |
| 385 | Mario | When the gui starts I show servers state. As soon as a teacher clicks a button for a room he is changing the state... | 18-May-07 20:21 |
| 384 | Maxim | so in reality, each time a computer opens up a view of the current state of each thing, it should have its own listener port. | 18-May-07 20:20 |
| 383 | Maxim | if someone else changes my setup, I have to be able to receive it. | 18-May-07 20:19 |
| 382 | Maxim | so using cgi for that kind of think (for liquid) is almost impossible, cause the viewers need to get the information BACK. | 18-May-07 20:19 |
| 381 | Maxim | you see, what I see here is that the actuall application data is on the server and your browser based plugins are just synchronised to it. | 18-May-07 20:19 |
| 380 | Mario | I POST compressed data | 18-May-07 20:18 |
| 379 | Mario | I compress the CGI request so it's not readable | 18-May-07 20:18 |
| 378 | Mario | Are you thinking about security risks? | 18-May-07 20:18 |
| 377 | Maxim | hum... and the proxy configuration is handled by small cgi requests? | 18-May-07 20:17 |
| 376 | Mario | It might be that a single computer should be opened instead of opening the whole room | 18-May-07 20:17 |
| 375 | Mario | Asking more the "open" rooms should be coloured in a different way so all teachers know thet Internet is available. | 18-May-07 20:16 |
| 374 | Mario | min=main | 18-May-07 20:15 |
| 373 | Mario | The min goal with the proxy is to open a specific room at a specifica time up to a specific hour or up to a limit hour (when the school closes) | 18-May-07 20:15 |
| 372 | Mario | I can maybe put some user-data to buttons to contain attributes | 18-May-07 20:14 |
| 371 | Maxim | ok, so what do you have to manage about the proxy? | 18-May-07 20:14 |
| 370 | Mario | The gui has the rooms names as buttons. When you press the room name its layout (made of buttons) is shown along with a standard feedback layout (a form to send requests via CGI POST) | 18-May-07 20:13 |
| 369 | Mario | The plugin posts data to a CGI on the proxy and that's how I can control the proxy and store requests for repair | 18-May-07 20:12 |
| 368 | Maxim | is the gui an actual picture of the school's layout. | 18-May-07 20:11 |
| 367 | Mario | Only some teachers will be able to have some buttons/nodes/handlers | 18-May-07 20:10 |
| 366 | Mario | The xcript runs in a webpage with plugin so the user cannot change the envvars | 18-May-07 20:10 |
| 365 | Mario | I've added flexybility putting the rooms in separate files and not in the script (as two school are using the same program), than I check the user of the LAN (I use the environment variables) | 18-May-07 20:10 |
| 364 | Maxim | so the control room is only available for that user? | 18-May-07 20:09 |
| 363 | Maxim | so at some point, you will have to add some intermediate nodes (plugs in liquid) to control the states themselves. before sendin them to the actual dependent systems. | 18-May-07 20:08 |
| 362 | Mario | Now they want me to add proxy handling to the rooms but the proxy should be handled only by some users (that's why I plan to have a controll room and not an extra button in computer rooms) | 18-May-07 20:08 |
| 361 | Maxim | now you see, since the structure of dependencies and synchronisation actually define the system... what you connect to what will basically define how much flexibility you have in your system. | 18-May-07 20:08 |
| 360 | Mario | The computer rooms ask for repairs is an old script I wrote for the cshool | 18-May-07 20:07 |
| 359 | Mario | I'd like to change the program to work with liquid but I have to be quick | 18-May-07 20:06 |
| 358 | Maxim | trying to help mario here grasp how to model a system using liquid. | 18-May-07 20:05 |
| 357 | Maxim | so continued from a discussion in VID+. | 18-May-07 20:05 |
| 356 | Maxim | I don't even have a copy of it. | 7-May-07 13:31 |
| 355 | Maxim | some very advanced GUIs where done with that engine... but alas, Its not my code, so I can't share it... | 7-May-07 13:31 |
| 354 | Maxim | ended up with scroll panes, menues, tree views, all matter of buttons and fiels. | 7-May-07 13:31 |
| 353 | Maxim | tcl/tk directly . not a single imported widget lib. | 7-May-07 13:30 |
| 352 | Pekr | what you used under the hood? wxWidgets? (PythonCard) | 7-May-07 13:30 |
| 351 | Maxim | same kind of list-based, free-form datatype and intutive. | 7-May-07 13:30 |
| 350 | Maxim | I did a VID dialect in Python... worked exactly like GLayout with the proportional resizing. | 7-May-07 13:29 |
| 349 | Pekr | think rebcode first :-) | 7-May-07 13:29 |
| 348 | Maxim | so I can make it hundreds of times faster. | 7-May-07 13:29 |
| 347 | Maxim | Its always been the vision... in fact I am eagerly waiting R3 to see how much of liquid I can port as C++. | 7-May-07 13:28 |
| 346 | Pekr | the trouble with toolkits like wxWidgets imo is, that those allow mostly traditional widgets, kind of RebGUI ones. Not free form faces with draw facitilies etc. | 7-May-07 13:28 |
| 345 | Maxim | python uses tcl and litterally converts python calls into tcp script and applies them as strings through the tcp interpreter... its soooo lame. | 7-May-07 13:28 |
| 344 | Pekr | So you can imagine porting your concpets elsewhere, e.g. Python? | 7-May-07 13:28 |
| 343 | Pekr | I wonder if other languages could benefit from View? I know they have e.g. wxWidgets, but not sure how easy would it be to integrate? Maybe with R3 as a whole, pythonists can link/load "rebol library" to do so :-) View simply needs rebol interpreter ... | 7-May-07 13:27 |
| 342 | Maxim | If I decided to go ahead with OpenGL and Elixir, using GLASS as the design... what is left of REBOL but the syntax and the interpreter anyways? I'd rather have the tool running on steroids without being tied to a chain. | 7-May-07 13:27 |
| 341 | Maxim | and I think he also understand the need for some of us to NOT be standard REBOL cause we are not writting small scriptlets. | 7-May-07 13:25 |
| 340 | Maxim | its what I have read between the lines... only the core is said to be closed source. and much of the reason for going open source IS view... many bugs would have been fixed ages ago.. I think Carl sees the advantage. | 7-May-07 13:25 |
| 339 | Pekr | are you sure it will be open-sourced? | 7-May-07 13:24 |
| 338 | Maxim | AFAICT the whole view will be opensource, so could probably retro fit a lot of ! | 7-May-07 13:23 |
| 337 | Pekr | it is good we saw some interview with Carl. It was talked on 3 forums. With R3 release, we could continue in that kind of "marketing", with some nice demos etc. | 7-May-07 13:23 |
| 336 | Pekr | I am curious, what Carl has in mind for View ... there were view plug-ins planned (dunno if it is the same concept as "rebol language plug-ins"?), which were supposed to provide you access to loaders, savers, and maybe even buffers? | 7-May-07 13:22 |
| 335 | Maxim | (obviously, liquid's lazy computing goes a long way into that.) | 7-May-07 13:20 |
| 334 | Pekr | nice .... | 7-May-07 13:20 |
| 333 | Maxim | (well elixir is already pretty smooth... much more than I would have anticipated... especially with so little in the way of optimisation so far) | 7-May-07 13:20 |
| 332 | Maxim | so if its done Like I think, using R3 elixir should be VERY interactive. and if that doesn't work, well, I can just use OpenGL later on. | 7-May-07 13:19 |
| 331 | Maxim | I can say I have probably helped Cyphre into a few decisions, which are old requests of mine. | 7-May-07 13:18 |
| 330 | Maxim | I know... and the gobs, match conceptually my globs... funny how the naming even got to be almost the same. | 7-May-07 13:18 |
| 329 | Pekr | well, whole new View is 100% AGG :-) Cyphre switched compositing engine to that of AGG internally AFAIK | 7-May-07 13:17 |
| 328 | Maxim | also note that currently, its 100% AGG/ | 7-May-07 13:16 |
| 327 | Maxim | the cool thing is the cross application capabilities.... need to insert a pic in a button... hum.. just use the output of the image creating node and plug it in the image input of a button. | 7-May-07 13:16 |
| 326 | Maxim | yep... waiting for R3 ... but the core engine can work over any GUI cause its decoupled. | 7-May-07 13:15 |
| 325 | Maxim | each node can be anything... a code block, a text prepropressor, a function def. | 7-May-07 13:14 |
| 324 | Pekr | or even a menu system ... would look cool in 3D, openGLed :-) | 7-May-07 13:14 |
| 323 | Maxim | the second module I'll be building for elixir. is a rebol IDE. | 7-May-07 13:14 |
| 322 | Maxim | and in fact, using elixir, many of the traditional need for "standard comms" becomes irrelevant as you build up apps on the fly, exactly as you need them. | 7-May-07 13:14 |
| 321 | Pekr | hmm, could it be used e.g. for rebol programming? e.g. each node would be your module? hehe, kind of cool IDE for rebol :-) | 7-May-07 13:13 |
| 320 | Maxim | now imagine being able to do all of those things together... litteraly. any exchange of data can go to any other process. | 7-May-07 13:13 |
| 319 | Maxim | the difference is in the loss of the "software" as a monolithic entity which modify files. | 7-May-07 13:12 |
| 318 | Pekr | watching video, editing photos, chatting on icq, altme, a little bit of rebol coding, browsing web :-) | 7-May-07 13:11 |
| 317 | Maxim | I'll ask a question... what do you do on your computer? well that is all of what elixir will be able to do once all the elements are in place. | 7-May-07 13:10 |
| 316 | Pekr | sounds cryptic to me - could you provide me with the example usage? | 7-May-07 13:10 |
| 315 | Maxim | I'm using a node graph as the basis for ALL system operations. for now, I'm just finishing the core framework, so the "tools" part is not yet in place, but I'll have a nice demo to open up the future of elixir. | 7-May-07 13:09 |
| 314 | Maxim | you=your | 7-May-07 13:08 |
| 313 | Maxim | Elixir is a first shot at redefining the concept of you workspace. | 7-May-07 13:08 |
| 312 | Maxim | but the colours are totally editable... it might take a few initial releases before I allow them to be editable in the API but internally all of that is very easy to change. | 7-May-07 13:08 |
| 311 | Pekr | Maxim - what will Elixir enable us to do? :-) | 7-May-07 13:07 |
| 310 | Maxim | thanks! yes, its always a matter of user useage, in the graphic editing world all the high-end apps use a dark scheme... | 7-May-07 13:07 |
| 309 | ? | Yes, looks good. May I suggest doing a "bright version" (white BG...etc. As if Mac designed this...) Although the dramatic colours always look striking, in the long run people tend to prefer the light colours so that they can use them easier in print and slide shows. | 7-May-07 13:05 |
| 308 | Maxim | thanks :-) took a bit of tweaking to get the stuff sorted out, but I'm starting to get the hang of AGG. | 7-May-07 12:47 |
| 307 | Anton | Those nodes look really nice. | 7-May-07 8:16 |
| 306 | Maxim | AS A TEASER FOR DEVCON... HERE IS THE FIRST EVER PUBLIC SCREEN SHOT OF ELIXIR ! http://www.pointillistic.com/open-REBOL/moa/steel/elixir/elixir_0_3_5.png | 7-May-07 7:05 |
| 305 | Maxim | it has a primitive version of the glob engine. It has grown since, but keeps the same basic idea. | 8-Mar-07 3:03 |
| 304 | Maxim | did you try out the regraph engine? | 8-Mar-07 3:03 |
| 303 | Steeve | demo ? | 8-Mar-07 1:14 |
| 302 | Steeve | glob glob glob ! | 8-Mar-07 1:13 |
| 301 | Maxim | applying this to a gui driven with liquid nodes, you could freeze the the whole layout on a modal window... and let your inputs continue to process in the background... updating animation, and reacting to async reads... for exacmple. when you unfreeze the gui and call a refresh of the gui plug, all the data which was being processed in the background, is now automatically available ,as if nothing had been frozen and a simple update of the node, will refresh you gui with nothing to manage. | 4-Mar-07 3:10 |
| 300 | Maxim | also since we have explicit knowledge of dirtyness of data, we can block I/O explicitely before or after some inputs have processed... so if you have a 'hide state for example, actually changing that state can send (or not) an update, so that the other inputs get used when it un blocks... and any one needing the value, will get the modified values, which where stored while the node was blocked :-) no data is lost, its only dormant. | 4-Mar-07 3:07 |
| 299 | Maxim | Just did a little research on programmatically controled I/O blocking (on demand) for a liquid node :-) this is very powerfull as it allows you to trigger your node's messaging only when some of the inputs are in specific states. making the engine able to prevent downstream nodes (observers) from knowing about upstream data changes, when they are not usefull. | 4-Mar-07 2:59 |
| 298 | Maxim | hehe I just realised that my graphic toolkit is very transparent... I have this line in my code: clear gel/liquid | 4-Mar-07 0:27 |
| 297 | Maxim | just like you can't just leave a gear loose inside a car's transmission for "whenever it might be needed" | 28-Feb-07 17:25 |
| 296 | Maxim | Its just cool that you can't leave any loose ends hanging around... otherwise the system just doesn't work. | 28-Feb-07 17:23 |
| 295 | Maxim | it just turns programming upside down and you have to think so differently that some impossible things are just plain trivial, and stupidly easy things become a design nightmare! | 28-Feb-07 17:22 |
| 294 | Mchean | I can relate to the second half of that statement | 28-Feb-07 17:21 |
| 293 | Mchean | " I made it, I understand it ... I just don't know how to use it" :D | 28-Feb-07 17:21 |
| 292 | Maxim | Like I told him " I made it, I understand it ... I just don't know how to use it" ;-) | 28-Feb-07 16:31 |
| 291 | Maxim | I implemented a simple session login with a neophyte on this list... and it was a good learning experience for both :-) | 28-Feb-07 16:30 |
| 290 | Maxim | so... its a bit tough at first, cause you can't just go in and start off quickly... especially since some coding practices have to change to adapt to the paradigm... but in the end, you have no cleanup phase. so its a fair tradeoff... | 28-Feb-07 16:30 |
| 289 | Maxim | what I am realising is that dataflow driven computing is more complicated to implement, but vastly superior in its ability to survive changes. Things like state changes or sequence-based computing is harder to implement, cause you have to explicitely manage states, in which imperative style, you just don't realise the FSM within. | 28-Feb-07 16:28 |
| 288 | Maxim | also, the fact that symmetric piping and dependency trees can co-exist with such triviality makes integrating GUI within networks really easy so far. | 28-Feb-07 16:24 |
| 287 | Maxim | liquidator is a good test bed for the engine, and so far, I have changed nothing in the design of liquid itself, I just keep improving how I link stuff and manage the liquid nodes themselves. | 28-Feb-07 16:23 |
| 286 | Maxim | so far its exceeding my expectations. although not dialected, the engine itself is very pliable and the lazy computing seems to pay off in general. | 28-Feb-07 16:22 |
| 285 | Mchean | you look like you are getting a lot of good mileage out of it though | 27-Feb-07 21:46 |
| 284 | Mchean | just cursory, i need to familiarize myself with rebol a little more | 27-Feb-07 21:41 |
| 283 | Maxim | have you tried liquid? | 27-Feb-07 21:40 |
| 282 | Maxim | ;-) | 27-Feb-07 21:40 |
| 281 | Maxim | by a very fast scan... this pretty much sums up liquid. | 27-Feb-07 21:40 |
| 280 | Mchean | Maxim: I know at one point you were looking at Sentences and the associative model. This sounds similiar: http://www.pilesys.com/new/news.php | 27-Feb-07 21:38 |
| 279 | Maxim | moving to chat | 17-Feb-07 3:21 |
| 278 | Steeve | a little bit | 17-Feb-07 3:21 |
| 277 | Steeve | i mean yes | 17-Feb-07 3:21 |
| 276 | Maxim | hummm should change group... polluting the liquid group... | 17-Feb-07 3:21 |
| 275 | Steeve | no | 17-Feb-07 3:21 |
| 274 | Maxim | did you try the rebcode version? | 17-Feb-07 3:21 |
| 273 | Steeve | thanks | 17-Feb-07 3:20 |
| 272 | Maxim | its actually not too bad on my pc... but it just crashed on me... nevertheless I am very impressed by your attempt... its already very good :-) | 17-Feb-07 3:19 |
| 271 | Maxim | obviously. | 17-Feb-07 3:18 |
| 270 | Steeve | currently it's to slow | 17-Feb-07 3:17 |
| 269 | Steeve | yes but to achieve this project and doing a real emulator, i need rebcode | 17-Feb-07 3:17 |
| 268 | Maxim | its actually quite functional... there are a few gfx issues... but its REALLY cool. :-) | 17-Feb-07 3:17 |
| 267 | Maxim | ;-) | 17-Feb-07 3:16 |
| 266 | Maxim | you should have done so for a C64! we'd have 100000 rebol games!!! | 17-Feb-07 3:16 |