[REBOL] Re: File writing issue
Just a few notes on the multiple appends for now; messaging server: ;compose the MIME formatted message m: append m EHLO^/ append m rejoin [MAIL FROM: return_email ^/] append m rejoin [RCPT TO: user_email ^/] append m DATA^/ append m MIME-Version: 1.0^/ append m Content-Type: multipart/mixed; boundary=unique-boundary-1^/ append m rejoin [Subject: subj ^/] append m X-MS-Has-Attach: yes^/ append m rejoin [Date: tstamp ^/] append m rejoin [From: return_email ^/] append m rejoin [To: user_email ^/] append m build-attach-body message files --unique-boundary-1 smtp: open/lines tcp://10.10.1.8:25 insert smtp m insert smtp . insert smtp QUIT close smtp You can join them all together with rejoin: m: copy ; copy ensures it a fresh new empty string append m rejoin [ HELO^/ MAIL FROM: return_email ^/ RCPT TO: user_email ^/ DATA^/ ; ... etc. ] Also this could be rewritten to add your newlines for you won't save you much code in this case, though: foreach line reduce [ HELO rejoin [MAIL FROM: return_email ] rejoin [RCPT TO: user_email ] DATA ; ... etc. ][append m join line newline] Anton. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Basic Script Calling Command
I don't know the answer to that, but I have made dir-utils.r, with more powerful cd and ls functions. I use them constantly. http://www.lexicon.net/anton/rebol/library/dir-utils.r You can extract the functions from that object and stick them in your user.r or you could use my include function. Full example: site: select load-thru http://www.reboltech.com/index.r [folder Anton] clear find site %index.r do load-thru site/library/include.r include [ site/library/dir-utils.r [cd ls] ; there are other functions ] ; now you can use cd and ls in console... eg. ; ls/info Find the code in your public cache here: path-thru site/library/dir-utils.r If I were you, I'd also define a function edit which launches your preferred native editor. Very handy. Here's mine on windows. edit: func [Open native editor file [file! string!] document to open in editor (can be empty string) /local exe ][ exe: %/d/Anton/Dev/EditPlus/EditPlus.exe call reform [ either file? exe [to-local-file clean-path exe] [exe] either file? file [to-local-file clean-path file] [file] ] ] Anton. Wow! How come I have never thought about this before? Thanks Anton Carlos Em Quinta 30 Outubro 2003 21:59, Anton Rolls escreveu: Ah a new linux guy. You may want to put these lines in your user.r for more familiar file system navigation: cd: :change-dir ls: :list-dir wd: :what-dir Usage: cd %adir/ Anton. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Coffee break problem anyone?
Thanks to (in order of message receipt at my end) Gabriele, Gabriele, Romano, Ladislav, and Joel for showing me better approaches. Parse is so powerful, I should try to learn to use it for more things that just breaking strings apart. Joel: This is a great little problem for comparing two approaches that handle state differently: classic stateful structured programming massages variables to maintain state, while the Jackson Structured Methodology maps data structure to algorithm structure as much as possible. Interesting discussion! I suspect most of us start out procedural -- trying to apply processes to what we see as static data structures. I admit I never was a great fan of JSP, but the insight that (in effect) the procedures can fall naturally out of an analysis of the data structures can lead to some very elegant solutions. Of course there are situations where neither approach works, and then you need other approaches too. Object-orientation is one claim to the next step as it merges both approaches. I never quite saw the point there, either, but it does work in some areas. And then there are situations that seem completely off the deterministic axis. Consider this progression: -- Find the sum of the numbers (simply almost any way: write a loop; use a map function, etc) -- Find the longest run with the highest end value (101--107 in the original data) -- Find the run (as defined in the original problem) whose run length is the modal length of runs --Find the two runs that are most nearly similar (contain mostly the same numbers) -- The numbers are RGB values from a JPG. Find the average color tone of the object the female nearest the camera is looking at. Break out the neural networks for this one! In my actual case, the patterns I was looking for grew more complex, so I reasoned that the requirement was becoming unreasonable as the preceding data structures weren't designed for easy sifting. Luckily, I could rewrite history (not always a luxury in this industry) and simplified the problem almost out of existence. Finally, this is getting a bit long, but just to stick up for the finite machine state approach I took in the original code. It isn't necessary to duplicate tests as my hacked-out original did -- see new improved (but already redundant) model below. But it is, as Joel notes, tricky to handle boundary conditions -- note the non-obvious way that largest-run-size is initialised. Thanks again everyone, Sunanda sparse-array: [ 12 13 14 15 16 17 7 8 20 21 22 23 24 25 26 19 59 58 57 56 55 54 53 52 20 21 22 23 101 102 103 104 105 106 107 ] ;;= find-longest-run: func [data-array [block!] /local current-state current-location run-size largest-run-size largest-run-start ] [ current-state: 0 current-location: data-array run-size: 0 largest-run-size: minimum 1 length? data-array ;; in case there is exactly one element largest-run-start: data-array ;; in case there are zero data items while [not tail? current-location] [ switch current-state [ ;; State 0: start of a new run ;; --- 0 [ run-start: current-location run-size: 1 current-location: next current-location current-state: 1 ] ;; end state 0 ;; State 1: next item ;; -- 1 [ either run-start/1 + run-size = current-location/1 [ ;; The run continues ;; - run-size: run-size + 1 current-location: next current-location ;; Update largest, if it's biggest so far ;; -- if run-size largest-run-size [largest-run-size: run-size largest-run-start: run-start ] ] [ current-state: 0 ;; the run has ended -- go start another one ] ] ;; end state 1 ] ;; switch ] ;; forever return reduce [largest-run-size largest-run-start] ] ;; func ;; Run some tests ;; -- set [run-size run-start] find-longest-run sparse-array print [Length: run-size Looks like: copy/part run-start run-size] set [run-size run-start] find-longest-run [1 2 3 4 5 ] ;; just one run print [Length: run-size Looks like: copy/part run-start run-size] set [run-size run-start] find-longest-run [999] ;; just one data point print [Length: run-size Looks like: copy/part run-start run-size] set [run-size run-start] find-longest-run [] ;; empty dataset print [Length:
[REBOL] A new case
Couldn't resist it I have hired Gabriele to build something with REBOL. It is like the Internet2 detective http://detective.internet2.edu but then with REBOL as a cross-platform wrapper. Providing a client and a client- and server installer. The result will be open source and feature a build-on-demand portal for multiple platforms (including a build protocol) based on the SDK for Windows, Linux, Solaris and *BSD. OS X will follow once that SDK is available. I will try to put the project plan online somewhere this week, so you can all take a peek at what is coming *this year*. --Maarten -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: A new case
Hi Maarten A good news... but only for SDK people. Indeed a very small part of the Rebol community. Regards Patrick - Original Message - From: Maarten Koopmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 10:11 AM Subject: [REBOL] A new case Couldn't resist it I have hired Gabriele to build something with REBOL. It is like the Internet2 detective http://detective.internet2.edu but then with REBOL as a cross-platform wrapper. Providing a client and a client- and server installer. The result will be open source and feature a build-on-demand portal for multiple platforms (including a build protocol) based on the SDK for Windows, Linux, Solaris and *BSD. OS X will follow once that SDK is available. I will try to put the project plan online somewhere this week, so you can all take a peek at what is coming *this year*. --Maarten -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Hitting the learning curve
I've read the recent 'losing the case' thread with interest. Personally, I've just come to the end of my honeymoon with Rebol. I've been throwing to gether 5 line scripts that do what pages of Java or VB do in 5 pages. I've stopped saying 'Wow,' and I'm starting to ask 'How.' The problem is that, given a blank piece of screen, where do I begin when devising my own code to solve my own problems. What is the starting point. Different languages have their own starting points. In VB I start with a blank form, dropping controls and then writing the event handlers. In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. What is the starting point with Rebol? Given a problem and an empty .r file how do I start growing my problem? With a form to enter the data? With a set of objects? With a set of functions? By defining a dialect? There seem to be so many approaches, but no single method affords itself? I can see there are some guys here who really know their Rebol - what approach do you take to a new Rebol project? Ged Byrne. Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: A new case
Patrick, The application is freely available to every end-user. We will communicate that through our normal channels, so not only good news for SDK people. --Maarten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: woensdag 5 november 2003 10:52 To: [EMAIL PROTECTED] Subject: [REBOL] Re: A new case Hi Maarten A good news... but only for SDK people. Indeed a very small part of the Rebol community. Regards Patrick - Original Message - From: Maarten Koopmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 10:11 AM Subject: [REBOL] A new case Couldn't resist it I have hired Gabriele to build something with REBOL. It is like the Internet2 detective http://detective.internet2.edu but then with REBOL as a cross-platform wrapper. Providing a client and a client- and server installer. The result will be open source and feature a build-on-demand portal for multiple platforms (including a build protocol) based on the SDK for Windows, Linux, Solaris and *BSD. OS X will follow once that SDK is available. I will try to put the project plan online somewhere this week, so you can all take a peek at what is coming *this year*. --Maarten -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: A new case
Hi Maarten, So it's a very very good news after all. Sorry for being pessimistic. Regards Patrick - Original Message - From: Maarten Koopmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 11:11 AM Subject: [REBOL] Re: A new case Patrick, The application is freely available to every end-user. We will communicate that through our normal channels, so not only good news for SDK people. --Maarten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: woensdag 5 november 2003 10:52 To: [EMAIL PROTECTED] Subject: [REBOL] Re: A new case Hi Maarten A good news... but only for SDK people. Indeed a very small part of the Rebol community. Regards Patrick - Original Message - From: Maarten Koopmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 10:11 AM Subject: [REBOL] A new case Couldn't resist it I have hired Gabriele to build something with REBOL. It is like the Internet2 detective http://detective.internet2.edu but then with REBOL as a cross-platform wrapper. Providing a client and a client- and server installer. The result will be open source and feature a build-on-demand portal for multiple platforms (including a build protocol) based on the SDK for Windows, Linux, Solaris and *BSD. OS X will follow once that SDK is available. I will try to put the project plan online somewhere this week, so you can all take a peek at what is coming *this year*. --Maarten -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
What is the starting point with Rebol? This is how I proceed for what it's worth. I start looking for related topics in the library. I appreciated most Carl examples which are the more Rebolish (or Rebolistic?). I have downloaded the entire Library in a folder named DOC. I store there all the documentations I have been able to collect about Rebol: The CookBook, The How-to, Zine articles, Ladislav document. I have also a special folder named Good to know where I store bits and tricks gathered from my own experience or from the Mailing List. After getting a more precise idea of the different parts needed, I start a new text document to write it down. Then I start a console session to test some points directly. I keep validated piece of code also in my text document. Very often, at this stage, some help is required from the ML. Finally if a GUI is needed, I start a simple layout which is refined progressively and noted in my text document too. At this stage, or earlier, my wife call me for this big thing that cannot wait and I am glad to have all my work written down waiting for me until I can resume a few hours or days later (depending on the big thing). Regards Patrick - Original Message - From: Ged Byrne [EMAIL PROTECTED] To: Rebol [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 10:49 AM Subject: [REBOL] Hitting the learning curve I've read the recent 'losing the case' thread with interest. Personally, I've just come to the end of my honeymoon with Rebol. I've been throwing to gether 5 line scripts that do what pages of Java or VB do in 5 pages. I've stopped saying 'Wow,' and I'm starting to ask 'How.' The problem is that, given a blank piece of screen, where do I begin when devising my own code to solve my own problems. What is the starting point. Different languages have their own starting points. In VB I start with a blank form, dropping controls and then writing the event handlers. In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. What is the starting point with Rebol? Given a problem and an empty .r file how do I start growing my problem? With a form to enter the data? With a set of objects? With a set of functions? By defining a dialect? There seem to be so many approaches, but no single method affords itself? I can see there are some guys here who really know their Rebol - what approach do you take to a new Rebol project? Ged Byrne. Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Patrick, Thanks for that. Are there any particular examples that deserve particular attention? I'm intrigued by your 'text document.' Is this document just your own notes, or Rebol? Thanks, Ged. Patrick wrote: | What is the starting point with Rebol? | | This is how I proceed for what it's worth. | | I start looking for related topics in the library. | I appreciated most Carl examples which are the more Rebolish (or | Rebolistic?). | I have downloaded the entire Library in a folder named DOC. | I store there all the documentations I have been able to collect about | Rebol: The CookBook, The How-to, Zine articles, Ladislav document. I | have | also a special folder named Good to know where I store bits and | tricks | gathered from my own experience or from the Mailing List. | | After getting a more precise idea of the different parts needed, I | start a | new text document to write it down. Then I start a console session to | test | some points directly. I keep validated piece of code also in my text | document. | | Very often, at this stage, some help is required from the ML. | | Finally if a GUI is needed, I start a simple layout which is refined | progressively and noted in my text document too. | | At this stage, or earlier, my wife call me for this big thing that | cannot | wait and I am glad to have all my work written down waiting for me | until I | can resume a few hours or days later (depending on the big thing). | | Regards | Patrick Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Hi Ged, What is the starting point with Rebol? I tend to start with an empty object which I fill with functions and data that gradually build up to the complete application. I have (though I'm not as well organized as some others) a few files named things like std-utils.r and gui-utils.r that contain generally useful functions -- many of them I've scavenged from other people on this list, or from REBOL.org. I generally aim to develop top-down, so I always have a working program, but it is always incomplete until I declare it finished. Working as one of the volunteers on REBOL.org has meant a slightly different approach. That is centered around persistent data structures (such as the scripts themselves, the user-information records, the discussion logs and so on). That takes some thought up front to make sure we have all the data fields we'll need, and that the items can easily be expanded when we realise we don't. Mainly, I used the experience to teach myself CGI programming, so there is a lot I'd do differently if the world was like Groundhog Day. It also involves a lot of interesting to-ing and fro-ing with, mainly, Gregg as we refine concepts (and a surprising amount of time on what we should call things) before we start cutting code. Sunanda. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Hi Ged Are there any particular examples that deserve particular attention? Yes, the ones that I down understand at the first look. Carl Sassenrath examples are often, but not always, of this kind. The source of mezzanine function is also interesting because the code is very short and concise. Is this document just your own notes, or Rebol? I keep there both notes and codes. I use copy and paste to test the code in the console. Regards Patrick - Original Message - From: Ged Byrne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 12:49 PM Subject: [REBOL] Re: Hitting the learning curve Patrick, Thanks for that. Are there any particular examples that deserve particular attention? I'm intrigued by your 'text document.' Is this document just your own notes, or Rebol? Thanks, Ged. Patrick wrote: | What is the starting point with Rebol? | | This is how I proceed for what it's worth. | | I start looking for related topics in the library. | I appreciated most Carl examples which are the more Rebolish (or | Rebolistic?). | I have downloaded the entire Library in a folder named DOC. | I store there all the documentations I have been able to collect about | Rebol: The CookBook, The How-to, Zine articles, Ladislav document. I | have | also a special folder named Good to know where I store bits and | tricks | gathered from my own experience or from the Mailing List. | | After getting a more precise idea of the different parts needed, I | start a | new text document to write it down. Then I start a console session to | test | some points directly. I keep validated piece of code also in my text | document. | | Very often, at this stage, some help is required from the ML. | | Finally if a GUI is needed, I start a simple layout which is refined | progressively and noted in my text document too. | | At this stage, or earlier, my wife call me for this big thing that | cannot | wait and I am glad to have all my work written down waiting for me | until I | can resume a few hours or days later (depending on the big thing). | | Regards | Patrick Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] function to object?
Am reading a little rant against object orientation http://www.bluetail.com/~joe/vol1/v1_oo.html When suddenly I wondered, can one convert a function to an object in rebol? -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Ged Byrne wrote: I've read the recent 'losing the case' thread with interest. Personally, I've just come to the end of my honeymoon with Rebol. I've been throwing to gether 5 line scripts that do what pages of Java or VB do in 5 pages. I've stopped saying 'Wow,' and I'm starting to ask 'How.' The problem is that, given a blank piece of screen, where do I begin when devising my own code to solve my own problems. What is the starting point. Different languages have their own starting points. In VB I start with a blank form, dropping controls and then writing the event handlers. Well, I can tell you one thing. I didn't like that aproach. I worked with VO, which was not so form based (which is imo bad aproach anyway), but with main window, defining menu, what menu items refer too, etc. - I hate those delphi/VB MDI apps. But that is not the point - even with VO, there was lot's of unneded stuff predefined in form of prebuilt apps, templates (even changeable but anyway) ... all this stuff provides you own logic of how child windows are stored, referred too, dbases organised etc. To not end with kludge, our team did exactly following - deleting whole stuff and astarting with main loop - we build our own system framework, classes, applied some DOS based keyboard navigation thru whole IS, we have done things like localisation and remote automatic update, we removed registry crap dependency etc. - and we were lucky . In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. That nearly seems as ideal case for project goals identification, but then I don't understand, what is your problem with rebol? If you are able to identify your goals with java, why not using rebol? After all - IIRC someone created class/method aproach for rebol too ... In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. I don't understand here What is the starting point with Rebol? Given a problem and an empty .r file how do I start growing my problem? With a form to enter the data? With a set of objects? With a set of functions? By defining a dialect? Hmm - as I said - you have to learn how to correctly identify project goals and how to fulfill them. Deciding between objects, functions, dialect - is after step. I will try to define my aproach later, but let me get back to dialects: I don't know if I am alone, but Rebol dialects (or dialects in general) can be cool thing as well as they can become very tricky. Rebol dialects are completly free form, so dialect author can introduce stuff looking as coming from Mars, as well as it can look as any other programming language :-) The problem is, proven using VID, that dialects don't fit rebol language correctly. I tried to think about it for a while, but I am not sure, how you can eg. dialect to work with official rebol help? How can you know (talking VID now), what styles are available, what are their facets? Not to mention catastrophe, when you need to mix dialect with rebol level (button OK with [rebol-code-here]) - you suddenly deal with whole underlying View infrastructure - and once again - there is no help mechanism for objects, so the only thing you are left for in the case of object is to 'probe it - I can guarantee you, that only handfull of ppl understands how styles are constructed, when does it happen, how whole event mechanism flows etc etc. Now general question - has anyone thought how to make this situation better? I am not sure there is an easy answer. As far as VID is concerned, I propose: - VID 1.3 - provide users with more robust and encapsulated styles (tree, grid, tabs) so ppl will not need to touch underlying engine too often - fix inconsistencies and bugs - new level of docs are imo needed - View engine description, working with events, effects at face level ... show how to build UI in non VID fashion. Then start to explain VID, e.g. single button style ... explain how and when certain things happen and show us how to customize button and build own style get-style 'button output is far from being enough ... But that is just VID of course ... There seem to be so many approaches, but no single method affords itself? OK, one other problem I can see with rebol is - lack of frameworks. Maybe I now understand your java aproach - maybe you have I have all and I have nothing at hand feeling with rebol. Sometimes I have feeling that if you want to do something using rebol, you have to start over and over again - from scratch ... missing more general mechanisms to work with. I don't want to use async:\\whatever kind of stuff - I want RT to decide what is good and what not, and if it is good it should be added to rebol, simply to provide such common base to all of us. Or e.g. things like Medusa multi-protocol server framework with plug-in system? I
[REBOL] Re: function to object?
Bryan: When suddenly I wondered, can one convert a function to an object in rebol? You can easily *add* a function to an object. a-function: func [a b /local c] [c: a + b print c] a-function 19 21 ;; test it works an-object: make object! [a-function-in-an-object: :a-function] an-object/a-function-in-an-object 19 21 ;; test it works too Sunanda. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Coffee break problem anyone?
Am Mittwoch, 5. November 2003 08:28 schrieb [EMAIL PROTECTED]: Thanks to (in order of message receipt at my end) Gabriele, Gabriele, Romano, Ladislav, and Joel for showing me better approaches. Parse is so powerful, I should try to learn to use it for more things that just breaking strings apart. Closed? I am to late? I guess its like Joels classic modell: sparse-array: [12 13 14 15 16 17 18 7 8 20 21 22 23 24 25 26 19 59 58 57 56 55 54 53 52 20 21 22 23 101 102 103 104 105 106 107 ] b: p: sparse-array ;b: begin of run best-b: none best-l: 0 forall p [ set [n1 n2] p if 1 + n1 n2 [;close run ;and if at end n2 = none ;) if best-l l: 1 + subtract index? p index? b [ best-b: b best-l: l ] b: next p ] ] ? best-b ? best-l probe copy/part best-b best-l ;Volker -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Hi Ged, I have a Scratchpad.r where i start developing. Thats the blank screen or the form. In VB I start with a blank form, dropping controls and then writing the event handlers. my vb-blank-area (text-area with slider, quit-button): view layout[ buttin #^q quit [quit] slider 16x450 [scroll-para ta face] area 600x450 ] starts with hotkey from my editor. error: console, a quick q in the console quits and i am back in editor. In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. Not so necessary in rebol imho, because most of the usefull classes are inbuild and very flexible. In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. me too. using 'save/all and 'load/all. Very usefull with rebol, because data is easy to structure (hierarchy of blocks), search and (!) to create by hand for debugging. my blank data-page: words: [files names something] ;persistent to load/save data-file: %scratchpad-data.txt save-data: does[save/all data-file reduce words] ;loading once at atart, so no func set words any[ attempt[load/all data-file] ; catchs errors, like does not exist reduce[[%a %b] [the a file the b file] #a-something] ] to reset data-file i usually put a single [ in, so the load fails, default values are used. So a blank page with gui and load/save is: words: [files names something] ;persistent to load/save data-file: %scratchpad-data.txt save-data: does[save/all reduce words] ;loading once at atart, so no func set words any[ attempt[load/all data-file] ; catchs errors, does not exist etc. reduce[[%a %b] [the a file the b file] #a-something] ] view layout[ buttin #^q quit [save-data quit] slider 16x450 [scroll-para ta face] area 600x450 ] ;; hacked a bit straightforward, have now a basic file-commenter used a lot probe something and ?? variable. usefull too: keep variables in global context while debugging. quick to look in. be carefull with attempt[load someting]. it hides all errors. so it hides wrong filenames too. while debugging, you can set attempt: :do so attempt will break on errors. You can do area/text: %file.r. but the filename is converted to string. will not be found in the initial file-block. so use find files TO-STRING area/text once file is stored, it will not look for new files. try to fix that. hints: union files read %./ appends, deletes doubles and keeps old order of first argument. insert/dup with the difference of two length? can be used to add nones to the comments-field. REBOL [Title: Scratchpad - for developing] words: [files comments] ;persistent to load/save data-file: %scratchpad-data.txt save-data: does [save/all data-file reduce words] ;loading once at start, so no func set words any [ attempt [load/all data-file] ; catchs errors, like does not exist reduce [ f: sort read %./ ;files head insert/dup copy [] none probe length? f ;a none-comment/file ] ] view layout [ button #^q quit [save-data quit] tl-files: text-list data files [ tf-file/text: first face/picked index: index? find files tf-file/text ta-comment/text: pick comments index show [tf-file ta-comment] ] return tf-file: info ta-comment: area [ index: index? find files to-file tf-file/text change at comments index copy ta-comment/text save-data ] ] ] ;-Volker Am Mittwoch, 5. November 2003 10:49 schrieb Ged Byrne: I've read the recent 'losing the case' thread with interest. Personally, I've just come to the end of my honeymoon with Rebol. I've been throwing to gether 5 line scripts that do what pages of Java or VB do in 5 pages. I've stopped saying 'Wow,' and I'm starting to ask 'How.' The problem is that, given a blank piece of screen, where do I begin when devising my own code to solve my own problems. What is the starting point. Different languages have their own starting points. In VB I start with a blank form, dropping controls and then writing the event handlers. In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. What is the starting point with Rebol? Given a problem and an empty .r file how do I start growing my problem? With a form to enter the data? With a set of objects? With a set of functions? By defining a dialect? There seem to be so many approaches, but no single method affords itself? I can see there are some guys here who really know their Rebol - what approach do you take to a new Rebol project? Ged Byrne. Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger
[REBOL] Re: Hitting the learning curve
Thanks Petri, Your post helped clarify my thinking a lot. I wasn't arguing for the form or object based approach, I was trying to point out that these langauges have a task flow. VB encourages me to build forms and Java encourages to build objects. They both offer lots of support for the creation of these. From my rather ponderous start, I think you have pinpointed what are my 2 main issues: - Lack of documentation - I have all and I have nothing at hand It seems that Rebol encourages me to do just one thing: to abstract. You suggest just taking the Java approach, and I could. The problem is that it doesn't feel right. When working for Java the is a massive amount of repitition. You just accept this as being part of java, and there are tools like IDEs and Code generators to help. When I try the same approach in Rebol, it feels wrong. One of the main appeals of Rebol is that all that typing can be generated. Instead of creating a set of interfaces and objects to describe my model of the real world, why not create a dialect to succinctly describe the model. This, I think, is where I hit the problem. While Rebol gives me tools to create abstractions, it doesn't give me any help to manage them. With Java I have Javadoc, class browsers, autocompletion in my IDE. There are so many tools to help me deal with the object structures being created, either by myself or somebody else. With Rebol this help does not exist. This is particularly accute when using somebody elses dialect, such as view. Once I have consumed the documentation, the only option is to either read the source (which I'm not advanced enough to understand yet) or use trial and error (which is time consuming and unreliable.) Fortunately, Rebol is so much fun to play with I keep going. However, though I love to play with it when it comes to getting some work done I find I can't quite use it. --- Petr Krenzelok [EMAIL PROTECTED] wrote: Ged Byrne wrote: [...] That nearly seems as ideal case for project goals identification, but then I don't understand, what is your problem with rebol? If you are able to identify your goals with java, why not using rebol? After all - IIRC someone created class/method aproach for rebol too ... In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. I don't understand here What is the starting point with Rebol? Given a problem and an empty .r file how do I start growing my problem? With a form to enter the data? With a set of objects? With a set of functions? By defining a dialect? Hmm - as I said - you have to learn how to correctly identify project goals and how to fulfill them. Deciding between objects, functions, dialect - is after step. I will try to define my aproach later, but let me get back to dialects: I don't know if I am alone, but Rebol dialects (or dialects in general) can be cool thing as well as they can become very tricky. Rebol dialects are completly free form, so dialect author can introduce stuff looking as coming from Mars, as well as it can look as any other programming language :-) The problem is, proven using VID, that dialects don't fit rebol language correctly. I tried to think about it for a while, but I am not sure, how you can eg. dialect to work with official rebol help? How can you know (talking VID now), what styles are available, what are their facets? Not to mention catastrophe, when you need to mix dialect with rebol level (button OK with [rebol-code-here]) - you suddenly deal with whole underlying View infrastructure - and once again - there is no help mechanism for objects, so the only thing you are left for in the case of object is to 'probe it - I can guarantee you, that only handfull of ppl understands how styles are constructed, when does it happen, how whole event mechanism flows etc etc. Now general question - has anyone thought how to make this situation better? I am not sure there is an easy answer. As far as VID is concerned, I propose: - VID 1.3 - provide users with more robust and encapsulated styles (tree, grid, tabs) so ppl will not need to touch underlying engine too often - fix inconsistencies and bugs - new level of docs are imo needed - View engine description, working with events, effects at face level ... show how to build UI in non VID fashion. Then start to explain VID, e.g. single button style ... explain how and when certain things happen and show us how to customize button and build own style get-style 'button output is far from being enough ... But that is just VID of course ... There seem to be so many approaches, but no single method affords itself? OK, one other problem I can see with rebol is - lack of frameworks. Maybe I now understand your java aproach - maybe you have I have all and I have nothing at hand
[REBOL] Re: lost the case ...
I don't worry about rebol. But i worry a bit about us. Eventually we are outgrown it? The simple for simple stuff, then the other features, this simple may be to easy for us? I like Carls recent style in the cookbook. Seems he has some fun with rebol for simple things again. Regarding cookbook: there are some examples which are quite usable to draw peoples to rebol. simply try to do that in other languages, and they would drop them. But rebols area is web-upload-scripts and searching IMHO. I agree the editor (area) is very weak in rebol. Not for real text-editing. not without emacs, vim, some others and word inbuild. (fast, rich-text, and everyones keybindings). the limit is the inbuild desktop-editor. usable for quick changes, for heavy tasks switch. field/area are good to show and enter stuff, its very repid to set up and use. Seeing such c#-examples i think Uh, writing that much since rebol. Instead of writing a real editor, i would like better connection to external editor. I can call my running emacs with file and line-number, and call rebol-scripts from there. could work for example as a file-requester in rebol, or calling text-processing scripts. -Volker Am Dienstag, 4. November 2003 00:34 schrieb Petr Krenzelok: Hi, today I lost second person who started with rebol some few months ago. Sorry if you will find my comments off-topic, or negative, but I can't resist. And what is more - I think current situation deserves some criticism. Maybe you will tell me you don't know how my lamenting can help rebol, but otoh I may ask you - how current state of no visible progress can help it either. I know there are several groups of rebol users - those who are real rebol hackers, who can accomplish really nice things using rebol, but otoh there is group of ppl, who will start to be frustrated, after some time of usage. Today I met such person - my long time friend. He is a programmer - average one. He tried to do very simply thing - press the button and insert some text into area, into caret position. While I am sure few even few lines solutions could be posted, the problem is, that my friend does not care anymore. And sadly - I have to agree with him, as the cause is: - VID is 70 - 80% complete, which means it pushes ppl to adapt styles. - styles don't provide proper encapsulation - why such thing as caret position of certain face is not simply a property of face object ... - styles are inconsistent from the point of user data storage - styles are incomplete in 'feel area of behavior - lack of View documentation ... I am (was) a programmer too. I think I know what I talk about. Don't get me wrong - VID is beautifull concept, but in current state it pushes ppl to often try to hack into View level, but then - there is a lack of documentation. When I learned Visual Objects, there were 2 things important - event model and class hierarchy. The same goes for View imo - I remember that with View beta 1 came one doc, which left VID completly - it explained how concept of faces, events, its filtering etc. works. I think, that from programmer's perspective, something like that should reappear and upon such doc things like VID should be explained. VID only docs are nice, if VID itself is complete enough so it will not push ppl to touch under its level ... I am also asked - for nearly one year - hey, - what is new with rebol? And I have to say - nothing. SDK here or there does not count. I know that money are priority probably, but in such case, I think that is is inproper identification of long term business strategy. I would not bother with SDK for BSD or so, but would focus onto bringing Rebol to mobile devices arena, OSx etc. Now read those and look into the dates: November 2002: Monthly State of the REBOLion updates - Starting as of this message we will provide regular monthly news updates to keep you informed. (We also hope to recruit members from the REBOL community to contribute useful information, hints, docs, and scripts.) http://www.rebol.com/news3203.html http://www.osnews.com/story.php?news_id=199 I think that those things should not be stated, unless fullfilled in reasonable enought timeframe. From external pov rebol totally lacks on development. I was trying to be helpfull as much as I could to my two friends, but they are not blind and I refuse to fool them around. I was also asked some two years ago to write about View for magazine of 12K monthly issues sold, but I refuse to, because of inability to guarantee any single thing regarding rebol's future. Gee, last official View release was when? Well, sadly I have to admit, that Rebol is becoming another Amiga - I will use it till the last day, but to be fair I would really have to think twice before suggesting Rebol to newcomers. Yesterday I received renewal for payment of rebol.cz domain. Some time ago I had intention to build some czech portal. I expected someone
[REBOL] Re: Coffee break problem anyone?
Hi Sunanda, ... but just to stick up for the finite machine state approach I took in the original code... you don't need SWITCH for a Finite State Machine implementation in Rebol (as has been discussed some time ago, Joel and others supplied nice examples), you can use functions or code blocks and DO. -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: function to object?
Am Mittwoch, 5. November 2003 13:53 schrieb bryan: Am reading a little rant against object orientation http://www.bluetail.com/~joe/vol1/v1_oo.html When suddenly I wondered, can one convert a function to an object in rebol? means what? f: func[][alert hi] o: context[f: none] o/f: :f o/f ;? or functions with state? o: context[ state: 1 set 'f func[][state: state + 1 alert mold state] ] f f f or? (reading article later ;) -Volker -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: lost the case ...
Am Dienstag, 4. November 2003 03:17 schrieb Tim Johnson: Now, given that scenario, suppose I've got rebol imbedded in my editor (which is VIM), just as python is imbedded in vim. If that were that case, I could program rebol to automate the writing of C. That would make for a remarkable plugin, and I'm sure that the vim developers and the vim community would work with RT to make that happen. that would be just awesome and give rebol that much more exposure. And BTW, I don't believe that RT would have to provide source code. Vim doesn't care about python binary source. ===Rebol as emacs-plugin: http://www.frozen-north-linuxonline.com/Howto/REBOL+Emacs.html http://www.frozen-north-linuxonline.com/Howto/REBOL+RMAIL.html I guess vim can work similar. ===some of my beginners emacs-code. it saves, calls a script, reads result and jumps to old position. in this case it prettyprints the sourcecode with rebols own cleaner.: (defun cleans () clear rebol script (interactive) (progn (save-buffer) (shell-command (concatrebol -cs ~/xenv/cleans.r (buffer-file-name (current-buffer (let((old (point))) (find-alternate-file (buffer-file-name (current-buffer))) (goto-char old) ) )) ===a rebol-script in the background: this o(not presented) script uploads the file with ftp. or downloads. or shows date and size and header of both. since its a shared ftp-site i want to check before. all actions are on hotkeys, so its c-x c-g c-u from emacs. (the c-u goes to the rebol-window ;) (defun run-uni () run rebol-buffer through emacs.r (interactive) (progn (save-buffer) (shell-command (concat rebol-binary -s ~/xenv/uni.r emacs (buffer-file-name (current-buffer)) )) ;;(other-window 1) (delete-other-windows) )) ===using emacs for the real editing from rebol (view 1.2.10 beta) line: length? parse/all copy/part d-area/text system/view/caret ^/ set-browser-path emacsclient browse probe join + [line a-file] wait 1 quit -Volker -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] long read, sorry... RE: Re: Hitting the learning curve
-- pekr -- I wont't quote you, I agree with all. Many people also have different views on how everything should work and do similar tools (RSP and my own remark.r are a good example), that is ok, but then it seems, not many actually wish to use those tools once we share them. That is deeply incrusted within rebol, you like it because you can do anything the way you like it, but then you feel lost, because not many released, rugged, tested, proven, tools exist (in the public eye) on top of which you can do it. THAT is the specific goal I want to achieve with steel. provide a common gateway for all tools to integrate, as though they were all wrought of the same iron. There are many facets in order to acheive this, but hey I can't wait for no one to do it, especially not RT. So I do it, stay focused on the end goal, even if its sometimes quite (read extremely) boring to code. comments on rebol/view: --- glass was built from the ground up using view. no vid code used anywhere. I had to learn view itself, and although I am now happy I had, cause I've created really advanced faces, it really was a pain to find all the information (some things still are mysterious). team management. -- If I can make a parallel with steel and RT, I think we suffer from the same problem. a fairly detailed release plan with a good idea of what it -should- be. the plans are large and include many things others are doing or trying to, but which aren't integrated. So if you have limited resources, to the exterior, it looks as if its really all ground to a halt, but its not the case. most suggestions are already in the detailed specs, most can't even fathom the advanced plans I have for steel, glass and liquid, but there is so much to do before, that sometimes I feel like I'll never get to them. I'm sure RT suffers from the same problem. the main difference between me and RT is that I try not be silent (I hope I'm not too loud though). I'm giving as much of what I'm doing so that people can see where its at. I also WANT people to participate... which seems to be contrary to RT's POV. BUT alas, it seems people only want to share efforts if their name is going to be included into RT's credits. Only wishing to work on projects with RT's stamp on it. it tooks years for rebol.org to get to what it is now, in the sence that I had also started to put effort in trying to get it go back live three years ago... but that never delivered, cause I was completely alone and stopped getting feedback from those who had the site's control. The PROBLEM I HAVE with the community is that many of us sit and wait and hope that either RT or some guru will create the tools they need. I agree that many tools are missing, but we should not wait, we should cooperate, in the end, even RT might use some or our code if its rock-solid. STEEL has always been open source minded, but no one seems to want to DO anything. I mean beyond saying sounds cool, I' might, I think, I hope. Only one person offered to do real concrete help with steel. and I lost his name in a computer swap which went bad, so I don't know who it is anymore (others than it was a french person, please come forwards again :) There are MANY extremely usefull tools. The real problem is that none share the same api, look and feel, or share some common philosophy. Most distribute their scripts in different forms, many aren't specifically released as code bases which are easy to reuse, or even meant to be linked to. Many scripts expect people to peruse the code and figure out how it works, or how to make it work within your code. Python and perl are success stories, because they did not depend on one holy person to do solve all miracles. They quicly setup a standard way to exchange and link code. They made it so that whoever wants to solve a specific person, can only create a linkable module which solves that specific issue and it gets ALL dumped into one archive, no matter where it came from. That way the author of the language can say, hey, they fixed that, I can work on something else. rebol.org is probably the one thing that might revive the community spirit, if it lives on. Many people only acknowledge efforts if they are supported for a long time... It is a way of knowing if the effort is genuine or if its just an impulse. no one wants to use a tool that will stop being supported a few weeks after its inception. Working as a team helps a lot, especially to keep motivation. I have something in the oven which will help the community to become more united, but I am scared that it too will be just another looks nice, sounds cool thing, even if it will be only be distributed in a release-level and supported state. IT would mean people adhering to a standard... oooh i said the evil word... standard. Most of us love rebol cause its not standards based (in terms of coding methods), you don't have
[REBOL] Re: Hitting the learning curve
-Original Message- From: Ged Byrne [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 9:43 AM To: [EMAIL PROTECTED] Subject: [REBOL] Re: Hitting the learning curve This, I think, is where I hit the problem. While Rebol gives me tools to create abstractions, it doesn't give me any help to manage them. my pet peeve too With Java I have Javadoc, class browsers, autocompletion in my IDE. There are so many tools to help me deal with the object structures being created, either by myself or somebody else. since every one is in on the discussion and you nailed it so good, I want to emphasise that this is specifically what steel|forge will be about... when it will exist. ciao! -MAx - Steel project coordinator http://www.rebol.it/~steel - -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: lost the case ...
Hi Max, MOA Nothing is worse than NOT knowing what people think. Hear, hear! I couldn't agree more. One of the things that is interesting about the REBOL community is that a single person *can* create really useful stuff; it doesn't require a team. Look at Rugby, pdf-maker, the async protocol stuff, Steel, Phil's email client, many of Carl's examples (EasyVID, make-doc--and it's derivatives, etc.), the REP site, and so many more! For a small community, we have so many things to keep up with, it's hard to support all of them. I try to do what I can in spare moments here and there, but I often feel I don't do enough. So, let me say THANK YOU! to everyone in the community for all the cool stuff you've done. I only wish I had time to play with them all. -- Gregg -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Rebol and vim: (was lost the case ...)
* Volker Nitsch [EMAIL PROTECTED] [031105 07:13]: Am Dienstag, 4. November 2003 03:17 schrieb Tim Johnson: Now, given that scenario, suppose I've got rebol imbedded in my editor (which is VIM), just as python is imbedded in vim. If that were that case, I could program rebol to automate the writing of C. That would make for a remarkable plugin, and I'm sure that the vim developers and the vim community would work with RT to make that happen. that would be just awesome and give rebol that much more exposure. And BTW, I don't believe that RT would have to provide source code. Vim doesn't care about python binary source. ===Rebol as emacs-plugin: http://www.frozen-north-linuxonline.com/Howto/REBOL+Emacs.html http://www.frozen-north-linuxonline.com/Howto/REBOL+RMAIL.html Hi Volker: Small World! That's an article that my partner and I published, written by Sterling Newton. :-). I guess vim can work similar. Sorry, I don't believe I made myself clear there. What Sterling writes about in that article is using 'plugins' *for* rebol. I'm talking about using rebol *as* a plugin. I have extensive plugins *for* rebol in vim, as do many others on this list. Those plugins are written in either native vim script or imbedded python. read on: Your emacs code below is elisp script, and the elisp interpreter is imbedded 'inside' of emacs. Vim has the 'hooks' to actually compile the following interpreters: ruby, python, perl,tcl (at least) into the vim executable - just as elisp is in emacs. Therefore one can write an editor plugin in any language that has it's binary inside of vim, just as you have writen the elisp code below, which is processed by the elisp interpreter, which is imbedded in emacs. This is comparable to the apache 'language modes', which essentially do the same thing for the perl, python, php etc. One of the neat things about Vim (and it's developers), is that it is a very inclusive design that is conceived to closely interact with other systems and applications. (One of the gnu-est of the gnu applications) Wouldn't it be cool if the 'emacs' (actually elisp) code could be written in rebol? I'd love it. For instance, yhere are extensive plugins 'for python' written 'in python' that turn vim into a full-fledge python IDE. BTW: Volker, I'm really interested in learning to program rebol in emacs, perhaps someday I could prevail upon you to share some of your elisp plugins with me. I orginally wanted to learn emacs, but I frequently would ask questions of comp.emacs and often those questions would go unanswered - unlike this ML and the vim ML - which is why I went with vim. For instance, emacs can't distinguish my imbedded keypad, where vim and Xemacs can.. and no one can tell me why or how to fix it. :-( And rebol and lisp are quite similar. Good thread! tim ===some of my beginners emacs-code. it saves, calls a script, reads result and jumps to old position. in this case it prettyprints the sourcecode with rebols own cleaner.: (defun cleans () clear rebol script (interactive) (progn (save-buffer) (shell-command (concatrebol -cs ~/xenv/cleans.r (buffer-file-name (current-buffer (let((old (point))) (find-alternate-file (buffer-file-name (current-buffer))) (goto-char old) ) )) ===a rebol-script in the background: this o(not presented) script uploads the file with ftp. or downloads. or shows date and size and header of both. since its a shared ftp-site i want to check before. all actions are on hotkeys, so its c-x c-g c-u from emacs. (the c-u goes to the rebol-window ;) (defun run-uni () run rebol-buffer through emacs.r (interactive) (progn (save-buffer) (shell-command (concat rebol-binary -s ~/xenv/uni.r emacs (buffer-file-name (current-buffer)) )) ;;(other-window 1) (delete-other-windows) )) ===using emacs for the real editing from rebol (view 1.2.10 beta) line: length? parse/all copy/part d-area/text system/view/caret ^/ set-browser-path emacsclient browse probe join + [line a-file] wait 1 quit -Volker -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- Tim Johnson [EMAIL PROTECTED] http://www.alaska-internet-solutions.com -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
[EMAIL PROTECTED] 11/05/03 03:49AM I've been throwing to gether 5 line scripts... The problem is that, given a blank piece of screen, where do I begin when devising my own code to solve my own problems. What is the starting point. I have exactly that same problem. I have used REBOL for little chores--moving files around the office, generating automatic email--but when I want to use it for something bigger my mind is blank as to how to start. Just last week I had an excuse to use it for something a bit bigger (but still small) so I have made a small crack in that barrier. Here is what I have so far, in case it helps. Languages are interesting not only for what one MAY say, but for what one MUST say. I come from a COBOL background (The use of COBOL cripples the mind... Edsger Dijkstra) so I'm used to having things that must be present, and must be in certain places, so I do that in REBOL to make myself comfortable. I also have found that the examples on the REBOL web site use words like file, data, and so on that trigger a reflex in my mind that says, That's a reserved word, and that is confusing. So to easy my confusion I type all the REBOL words in lower case and all the words of my own invention in upper case, just like old COBOL. It is not recommended as a style, but it helps me personally. I hope that as I go along I can develop a collection of reuseable, or at least reconfigurable, scripts that I can call into my main program with the do (script-name) command. I have one so far, which is a language module. It contains every scrap of text that the main program will show in any way. The idea it that by isolating all text in one file, I could move the script to another language by translating that one file. I hope to write it up for the cookbook this week. The final form of a finished script will be something like this: ** The header ** do commands to bring in any reuseable modules ** Declarations of any configuration data items that the user might want to change. ** Declarations of all other data items. ** All screens, defined with the layout function, each followed by all the code that is run when the various controls are activated. ** The main program or first executable instruction to get the program running. With those preliminaries explained, here is how I proceed for a script that has a GUI screen and does stuff when you push buttons, etc. Draw out the screen, physically or mentally, so I have some idea of what I am trying to accomplish. Copy a skeleton of the REBOL header as my new script file, and fill in all the stuff. This just gets me warmed up, gets a little momentum going. Put in a do %language.r command to bring in the language file, which at this time is just a skeleton. (I'll put this do into the header skeleton eventually.) If I can see far enough ahead to know what data items I will be dealing with, I will declare them. This is not necessary in REBOL, but I like to do it to keep track of things. Declaring them is just setting them to some initial value in some standard spot in the script, so I can look back at them later and remember how to spell their names. This is like DEFAULT-FILENAME: %.xxx FORMATTED-DATA: none and so on. As I go on, I will add more items. I also document each item in comments in the script so I don't forget what they are and use them for the wrong purpose. I tend to go overboard on comments, so I have heard from my co-workers. Then I define the(all) screen(s). I use just the layout function, as MAIN-WINDOW: layout [ (VID commands)... ] Now, when I set up any text, button, etc. in the layout, the text that is to appear is NOT coded as a literal in the layout. It is coded as a data name in the language file. For example: button 60x20 LMB-001 LMB-001 might refer to a value of OPEN in the language file. So during this layout development I also am making entries in the language file, like LMB-001: OPEN For any screen control that can cause some action, usually a button, I use a function call as that action. Even if the action is as simple as quit, I use a function call. This is because I like things tidy, and so that if that action becomes more complex, I don't have to rework the formatting of the script so much. For example: button 60x24 LMB-001 [BUTTON-ACTION] [inform LMH-001] In the above example, BUTTON-ACTION is a function in the script. The other action, inform LMH-001, is the inform command which will display a help text on a right click. That help text is a layout in...the language file. So as I am setting up buttons, I am also adding items to the language file. I will define as many screen items as I feel like, just to get something that can be displayed. I won't necessarily do the full screen, or all screens, at this time unless I have a clear idea of what everything will be like, or unless I have a good head of steam. Then I
[REBOL] Re: Coffee break problem anyone?
Volker: Closed? I am to late? I guess its like Joels classic modell: It's never too late for a coffee-break. Thanks for the entryI get the feeling that if I stare at it long enough, it'll start to make sense; or maybe I've had too much coffee today :-) Anyone wanting a bigger challenge (may need a whole pot of coffee), there is an ongoing programming competition here: http://members.aol.com/bitzenbeitz/Contests/ REBOL *ought* to be a good language for solving it -- and there's money as prizes, Sunanda. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Rebol and vim: (was lost the case ...)
Hi TIm, Am Mittwoch, 5. November 2003 18:20 schrieb Tim Johnson: * Volker Nitsch [EMAIL PROTECTED] [031105 07:13]: Am Dienstag, 4. November 2003 03:17 schrieb Tim Johnson: Now, given that scenario, suppose I've got rebol imbedded in my editor (which is VIM), just as python is imbedded in vim. If that were that case, I could program rebol to automate the writing of C. That would make for a remarkable plugin, and I'm sure that the vim developers and the vim community would work with RT to make that happen. that would be just awesome and give rebol that much more exposure. And BTW, I don't believe that RT would have to provide source code. Vim doesn't care about python binary source. ===Rebol as emacs-plugin: http://www.frozen-north-linuxonline.com/Howto/REBOL+Emacs.html http://www.frozen-north-linuxonline.com/Howto/REBOL+RMAIL.html Hi Volker: Small World! That's an article that my partner and I published, written by Sterling Newton. :-). Thanks for publishing :) I guess vim can work similar. Sorry, I don't believe I made myself clear there. What Sterling writes about in that article is using 'plugins' *for* rebol. I'm talking about using rebol *as* a plugin. I have extensive plugins *for* rebol in vim, as do many others on this list. Those plugins are written in either native vim script or imbedded python. read on: I think you made yourself clear :) Sterling describes in http://www.frozen-north-linuxonline.com/Howto/REBOL+RMAIL.html how he uses emacs + rebol to filter his email. thats not a tool to write rebol-scripts. Its more like one would process python-scripts with rebol. The differecence to vim+python: rebol works more like a cgi-script. my typical use is: emacs stores file, calls rebol with filename to process and reads file back. the rebol-script can do anything, even process python-source. The interaction with emacs may not be as good as in elisp, but for preprocessing, indexing and such quite ok. Your emacs code below is elisp script, and the elisp interpreter is imbedded 'inside' of emacs. Vim has the 'hooks' to actually compile the following interpreters: ruby, python, perl,tcl (at least) into the vim executable - just as elisp is in emacs. Therefore one can write an editor plugin in any language that has it's binary inside of vim, just as you have writen the elisp code below, which is processed by the elisp interpreter, which is imbedded in emacs. This is comparable to the apache 'language modes', which essentially do the same thing for the perl, python, php etc. elisp is only the glue, keymapping, save file, call rebol, load file. rebol could even general the glue *.el -files. One of the neat things about Vim (and it's developers), is that it is a very inclusive design that is conceived to closely interact with other systems and applications. (One of the gnu-est of the gnu applications) i guess cloesely interact would be more tricky. in emas there is a way to send it elisp AFAIK, so rebol could control emacs remotely. but thats to high level for my emacs-knowledge till now. Wouldn't it be cool if the 'emacs' (actually elisp) code could be written in rebol? I'd love it. For instance, yhere are extensive plugins 'for python' written 'in python' that turn vim into a full-fledge python IDE. What means IDE? if its lots of buttons producing code, i prefer to do that in rebol. fire it up from emacs, click the buttons, shut it down and emacs pops up. have to learn more emacs to make it really comfortable, currently it tells me all the time the file has changed and i shall enter yes for reload, but basically it works. usually i don't switch to often, i complete either a lots of editing job or change and run or a gui-thing. so the occasional yes is not such a big problem. BTW: Volker, I'm really interested in learning to program rebol in emacs, perhaps someday I could prevail upon you to share some of your elisp plugins with me. I orginally wanted to learn emacs, but I frequently would ask questions of comp.emacs and often those questions would go unanswered - unlike this ML and the vim ML - which is why I went with vim. I use emacs because of the elisp-rebol-similarity too. thanks again for sterlings elisp-intro :) to me emas .rebol has its strong points on entering snippets with /vid and writing forms for that and sending it through the web. and copying files for more real work applications. emacs does this based on a strong editor, doing everything with text. both can access the web well, search and link. Related to a current discussion, emacs has all the bells and whistles rebol lacks. people complain its to complex. which i agree. i code in rebol. when i lack bells or whistles there i switch to the emacs-maual. Study a bit and find a way to do it nonwhistling in rebol and call
[REBOL] Re: Hitting the learning curve
Am Mittwoch, 5. November 2003 18:56 schrieb Steven White: [EMAIL PROTECTED] 11/05/03 03:49AM I come from a COBOL background (The use of COBOL cripples the mind... Edsger Dijkstra) so I'm used to having things that must be present, and must be in certain places, so I do that in REBOL to make myself comfortable. I also have found that the examples on the REBOL web site use words like file, data, and so on that trigger a reflex in my mind that says, That's a reserved word, and that is confusing. So to easy my confusion I type all the REBOL words in lower case and all the words of my own invention in upper case, just like old COBOL. It is not recommended as a style, but it helps me personally. There is a script somewhere, %colorize.r? rebol.org? it takes a script and outputs colored html. words found in rebol itself have a diferent color.AFAIK. could be used/modified to show scripts with your own words more marked up. ALso words like file, data etc are reserved in a way. whenever i nedd a local variiable for a file, i call it file, when its the file-content, or the important data in a face, thats data, etc. ta and sl are always the big text-area and the sliider in my layouts. so when code has a similar structure, it uses similar names and i can read it quicker. to trap inbuild words, use protect-system at start. then, when you overwrite an inbuild word, that triggers an error. since i initially my own words first, that traps very well. Another way i experiment with is to prepend my words with a shortcut, like d-something. thats mostly to keep emacs happy when looking up definitions. but could tell its my too. -Volker -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Am Mittwoch, 5. November 2003 15:49 schrieb Volker Nitsch: view layout[ buttin #^q quit [quit] slider 16x450 [scroll-para ta face] area 600x450 ] Correcting myself, thats view layout[ buttOn #^q quit [quit] RETURN slider 16x450 [scroll-para ta face] RETURN TA: area 600x450 ] of course -Volker -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
Steve: I come from a COBOL background (The use of COBOL cripples the mind... Edsger Dijkstra) Well, he also wasn't fond of the go to statement (in any language), so he did make some good points too :-) http://www.acm.org/classics/oct95 Sunanda -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Coffee break problem anyone?
Hi, Sunanda, First, let me offer an improvement and then address some more of the good discussion points you raise. (There's a little challenge at the end for the interested who wade through to that point! ;-) Minor issue first: instead of initializing run length to zero and incrementing for each added element, just directly calculate the length once the run is finished. Now for the more interesting stuff... Instead of saying that: - a block is an iteration of runs, and - a run is an iteration of numbers; block --*-- run --*-- number lets say that: - a block is an iteration of runs, and - a run is a first number, followed by any consecutive numbers. +-- first number | block --*--+ | +--*-- consecutive number This (again) addresses a boundary issue; the first value in a run plays a different role than the other numbers in the run. Tricky setup of initial conditions so that the first value can be treated just like all the others adds more complexity to the code. That said, here's a version that implements that view: where-j: func [ block [block!] /local maxpos maxlen runpos runlen prev curr ][ maxpos: maxlen: 0 ; default empty run while [not empty? block] [; more data = more runs runpos: index? block ; start new run here prev: block/1 ; remember first value block: next block ; done with first while [ prev + 1 = curr: block/1 ; extending the run ][ prev: curr; save comparison value block: next block ; move on ] runlen: (index? block) - runpos ; now compute length if runlen maxlen [ ; update best run? maxpos: runpos maxlen: runlen ] ] reduce [maxpos maxlen]; return best run ] [EMAIL PROTECTED] wrote: ... the insight that (in effect) the procedures can fall naturally out of an analysis of the data structures can lead to some very elegant solutions. Of course there are situations where neither approach works, and then you need other approaches too. Object-orientation is one claim to the next step as it merges both approaches. I never quite saw the point there, either, but it does work in some areas. I'm not clear on what you mean by both approaches... I view JSP (Jackson Structured Programming) simply as a specific type of structured programming which has strong heuristics about which structure(s) should drive the design. And then there are situations that seem completely off the deterministic axis. ??? Do you mean non-deterministic programming, or just programming when the criteria are only vaguely stated? Consider this progression: -- Find the sum of the numbers (simply almost any way: write a loop; use a map function, etc) Easy. Agreed. -- Find the longest run with the highest end value (101--107 in the original data) An easy extension of the above program: - add a local MAXTOP initialized to anything - change the condition at the end from runlen maxlen to any [runlen maxlen all [runlen = maxlen prev maxtop]] - change the new best run block to include maxtop: prev (For why this was easy, see below...) -- Find the run (as defined in the original problem) whose run length is the modal length of runs First, we have to change the run to a run, since the answer is no longer unique. For the data [10 8 9 6 7 4 5 0 1 2] there are runs of length 1, 2, 2, 2, and 3, so the mode length is 2, and there are three runs that have that length. However, something more significant has happened. The previous change to the problem (longest run with highest upper value) actually had THE SAME STRUCTURE as the original problem: find the best run, where we have a simple test for determining whether one run is better than another. In other words, we can generate runs one at a time, and test each one against the current best to see which one wins. But in this last change, we now are asking for a run based on some property/ies of the entire collection of runs, so we must generate (and retain) all of them. We can (trivially) change the above function to return all runs, then write a separate pick a median function to operate on that collection (or we build the additional stuff into the end of the modified function). In either case we now have a two-step approach: 1) transform the offered block into a collection of runs; 2) do something with the collection of runs. That's why the first change was easy and the second one was harder. --Find the two runs that are most nearly similar (contain mostly the same numbers) I think I
[REBOL] Re: Hitting the learning curve
Hi, Volker, Volker Nitsch wrote: Am Mittwoch, 5. November 2003 18:56 schrieb Steven White: ... So to easy my confusion I type all the REBOL words in lower case and all the words of my own invention in upper case, just like old COBOL. It is not recommended as a style, but it helps me personally. There is a script somewhere, %colorize.r? rebol.org? it takes a script and outputs colored html. words found in rebol itself have a diferent color.AFAIK. could be used/modified to show scripts with your own words more marked up. All of the above is more reason to use vim (or some other equivalent editor) that does syntax coloring. My normal development environment for REBOL is one or more vim windows (or terminal windows with vi[m] running in it/them, depending on platform) and a REBOL console. The edit/test cycle simply toggles between windows, and the syntax coloring is always there (without the need to run some utility to get a static view of the code that's outdated with the next editor keystroke). -jn- -- -- Joel NeelyjoelDOTneelyATfedexDOTcom 901-263-4446 Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Standards
Max wrote: IT would mean people adhering to a standard... What kind of standards are you thinking of? I'd like to know more. Andrew J Martin Attendance Officer Speaking in tongues and performing miracles. Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/ DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally liable) for materials distributed to or acquired from user e-mail accounts. You can report any misuse of an e-mail account to our ICT Manager and the complaint will be investigated. (Misuse can come in many forms, but can be viewed as any material sent/received that indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate language and/or other issues described in our Acceptable Use Policy.) All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0 Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [EMAIL PROTECTED] -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: function to object?
Hi, Bryan, bryan wrote: Am reading a little rant against object orientation http://www.bluetail.com/~joe/vol1/v1_oo.html Rant being the operative word. One can tell from the title that this is somebody venting his spleen and not contributing to any objective discussion of programming styles. It goes downhill from the title, as the author proclaims his philosophical/political views as if they were facts of nature. A collegue once described to me his moment of enlightenment when a professor had drawn on the blackboard a table showing relationships between some functions and data structures, something like: |Fn0|Fn1|...|Fnx| ---+---+---+---+---+ DS0| * | * | | * | ---+---+---+ +---+ DS1| | * | | | ---+---+---+ +---+ ...| | ---+---+---+ +---+ DSy| * | | | * | ---+---+---+---+---+ and then remarked offhandedly, If you slice it vertically, you have functional programming; if you slice it horizontally, you have object- oriented programming. When suddenly I wondered, can one convert a function to an object in rebol? Your question highlights the main irony regarding the rant cited above: at a deep level (e.g. the kind of thing well-illustrated in SICP) there isn't much difference. Functional folks are very fond of the idea of closures, which are basically functions that preserve state. For example (a very dinky example, to be sure! ;-) suppose we have this: times: func [a [number!] b [number!]] [ a * b ] and then we discover that we're using the (sub-)expression times 2.54 somelength frequently in our code. We could define in2cm: func [a [number!]] [ times 2.54 a ] quite easily. But then we notice that we also have lots of (sub-) expressions using times 4.546 somegallons and times 0.4535924 somepounds etc... Wouldn't it be nice to make a function factory that would freeze the first argument to TIMES and give us back a specialized function for a particular class of uses? We could try bogus-product-factory: func [a [number!]] [ func [b] [times a b] ] and then define (and use) in2cm: bogus-product-factory 2.54 in2cm 4 == 10.16 So what's wrong? Well, if we subsequently use our bogus factory to define a new function gallons2liters: bogus-product-factory 4.546 gallons2liters 10 == 45.46 gallons2liters 3 == 13.638 it behaves as expected until we try to use the first one in2cm 4 == 18.184 OOOPS! The gotcha is that both in2cm and gallons2liters are referring to the argument of bogus-product-factory as one of their factors, so a new use of the factory can change the behavior of one of its former products! Time for a factory recall! ;-) We can sidestep that problem (in this trivial case) as follows: compose-product-factory: func [a [number!]] [ func [b] compose [times (a) b] ] in2cm: compose-product-factory 2.54 in2cm 4 == 10.16 gallons2liters: compose-product-factory 4.546 gallons2liters 10 == 45.46 gallons2liters 3 == 13.638 in2cm 4 == 10.16 but that solution doesn't scale well at all. Instead, we can use an object to maintain the hidden factor in our functions like so object-product-factory: func [a [number!]] [ get in make object! [ constant: a f: func [b [number!]] [times constant b] ] 'f ] and we still have nice resulting behavior in2cm: object-product-factory 2.54 in2cm 4 == 10.16 gallons2liters: compose-product-factory 4.546 gallons2liters 10 == 45.46 gallons2liters 3 == 13.638 in2cm 4 == 10.16 We're simply encapsulating the state (the constant factor for each special case) inside an object, because that's what Tiggers do best! But wait! our anti-object screed-monger may cry You're not mutating the state, so your functions are still -- ermmm --- functional! So far, so true, but now our management (or our capacity-planning group, who wants to know how many CPU cycles we're burning up on multiplications) asks how many times each of our special-purpose conversion functions is being used. No problem! we say because we're using objects! object-inventory: [] accounting-product-factory: func [a [number!] /local obj] [ append object-inventory obj: make object! [ constant: a usage: 0 f: func [b [number!]] [ usage: usage + 1 times constant b ] ] get in obj 'f ] and now do our stuff again in2cm: accounting-product-factory 2.54 gallons2liters: accounting-product-factory 4.546 in2cm 4 gallons2liters 10 gallons2liters 3 but now we can also have inventory-usage-report: func [/local count usages] [
[REBOL] Re: function to object?
Thanks for that wonderful post -- all of it ! - Jason - Original Message - From: Joel Neely [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 5:26 PM Subject: [REBOL] Re: function to object? -- snip-- A collegue once described to me his moment of enlightenment when a professor had drawn on the blackboard a table showing relationships between some functions and data structures, something like: |Fn0|Fn1|...|Fnx| ---+---+---+---+---+ DS0| * | * | | * | ---+---+---+ +---+ DS1| | * | | | ---+---+---+ +---+ ...| | ---+---+---+ +---+ DSy| * | | | * | ---+---+---+---+---+ and then remarked offhandedly, If you slice it vertically, you have functional programming; if you slice it horizontally, you have object- oriented programming. --snip-- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: long read, sorry...
Hi Max, I can see where you are coming from. One of the problems with email as a forum for discussion is that too much becomes noise and too little can be mistaken for apathy. My own perspecive on some of the issues you (and pekr) have raised follows. The REBOL community, such as it is, probably has a more diverse background than other technical communities, with some areas of note being: - A good mix of people from multiple OS backgounds (Windows, *NIX, Mac, Amiga, other) - Different positions / perspective on the proprietary / open source / licencing question(s) - Programming background (C [and derivatives such as Perl / Java], Basic, Lisp, COBOL, etc) - Involvement (full-time, part-time, academic, professional, hobbyist, student, etc) - Skill-level (general programming and / or REBOL-specific) - Interests / focus within REBOL (GUI / graphics, Web / CGI, email, concepts, dialects, parse, algorithms, etc) This diversity is a *good* thing IMHO, and quite different from, say, the PERL community which might come predominantly from an open-source *NIX C background. That's not a bad thing in its own right, but mono-cultures are not the domain of MS alone! ;) In my case, running a software company that uses REBOL on Windows exclusively, I spend eight hours a day with REBOL. Digesting each day's REBOL list email takes about an hour of that time. I'd love to respond to / participate in more of the discussions but time is a big factor for me. I try to at least look at every REBOL project that is released (pdf-maker, konka, mysql protocol, rugby, async, steel to name but a few) but tend to focus on those that meet the following requirements: - they do not already do something that REBOL does *or* could be easily implemented (by me) in REBOL - they address a specific requirement that I currently have - they are stable (it works, and changes don't invalidate what I have done) pdf-maker and the mysql protocol are good examples of others code I have used to solve specific reporting and database requirements respectively. I started looking at rugby for simple client / server comms, but as often happens, this list provided a dozen line solution to my problem so I ended up rolling my own. Does this mean I will never use rugby? No. Does this mean I don't appreciate the effort the author put into the project or their generosity in making the fruit of their labour available to others? No. The reason I have this preference to roll my own is that I want to understand / control as much of the problem domain as possible, in as few lines of code as possible. I prefer using code with the RT stamp of approval as I only have to worry about the entry-points not the details (with non-RT code I find myself thinking of it as external and wanting to verify / understand its implementation). I suppose REBOL has spoiled me in this regard as its extensions are predominantly source-based (unlike black-box binary extensions). I would hazard a guess that most folks who spend some time with VID have some sort of GUI library script with various pre-defined styles and / or functions that they use. Is it a bad thing that we don't all use a common community defined GUI library? No. My GUI library does the following things: - defines a base element size based on current font size - uses stylize/master to standardize the size of all widgets - sets default origin and spaceing based on current font size These meet *my* requirements to have a GUI that can be specified in a cell-like manner and adjusts dynamically to font size changes. It's not complex, but it gets the job done. Would it meet anyone else's requirements? Maybe a subset or a superset but not an exact fit. Steel looks quite innovative and I like the fact that it is built directly on View. If and when RT releases VID 1.3 I'll put the time in to look at what each offers me and where I'm best off putting my limited RD time. Will I contribute to steel discussion / development? If I end up using it, you bet! Regards, Ashley -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Hitting the learning curve
And who is that? Anton. At least IOS situation looks a bit better last months as there is someone who cooperates with RT on its further development. -pekr- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
