AltME groups: search

If you are happy to copy the data to a new structure....

    newblock: copy []

    foreach [a b c d][ fld1 fld2 fld3 fld4 fld1 fld2 fld3 fld4 ] [
      append/only newblock reduce [a b c d]
      ]

Thanks Sunanda, it's cos some of the data (lists) I pick up may be 
in form one or form two. But either may be quite large lists - obiously 
if it's in memory doubling it may be a problem!

it's a supplement to sunanda's example. if you use newblock: copy 
[] you are correctly creating a new block, but every time you then 
append to that block, REBOL has to spend a little time allocating 
new space for the block as it grows. if you preallocate space with 
say:

newblock: make block! 10000


REBOL won't have to do that. This means that when REBOL must garbage 
collect or when you use 'recycle, it knows that there's one big block 
there that it can just remove. Easier for REBOL. Having more blocks 
inside that block makes the case a bit more complex, but since each 
block inside is only created and manipulated once, there may not 
be an issue.

my way was just a simple way of allocating exactly the space you 
need. if you can get the length of the input block and the number 
of items you want to split it in, then you can correctly determine 
the necessary length of the output block.

in REBOL it's generally a good idea to reuse blocks, if you are doing 
buffers. make your buffer global:

buffer: make binary! 4096  ; 4 kb buffer

loop [
  insert buffer *some stuff that needs to be buffered*

  *use buffer for something*

  clear buffer
]

but... it's a good idea to study some things here about which loop 
functions are faster than others.

Thanks Henrik.....For large blocks, you can help REBOL's memory managemeny 
by pre-allocating the needed space. So, applying Henrik's optimisation:

    oldblock: copy [ fld1 fld2 fld3 fld4 fld1 fld2 fld3 fld4 ]
    newblock: make block! (length? oldblock) / 4

    foreach [a b c d] oldblock [
       append/only newblock reduce [a b c d]
      ]

in sunanda's example, APPEND is actually a mezzanine. if you wanted 
a tiny speed up, INSERT/ONLY TAIL is a little faster than APPEND/ONLY

....My computer took about a second to reformat the test data. Fast 
enough?

Thanks Henrik, I was a bit confused by looking thru the core and 
dictionary functions - the examples don't really show advantages/disadvantages 
for real world apps

and once again, we'll be turning this upside down for REBOL3. :-) 
there are a lot of new functions to aid in the creation and manipulation 
of blocks with simple code that also performs very well.

sorry this wireless keyboard has a stutter ;-)

generally about speed: I rarely worry about REBOL/Core speed. I made 
a database once that was mainly about in memory block manipulation 
in REBOL. On an old 500 Mhz Celeron laptop, I couldn't saturate it, 
when throwing queries at it from 3 fast PCs over a 100 MBit LAN. 
I think it was about 100-1000 times faster than a MySQL database, 
but of course with the price that it's in-memory and that it had 
very few features.

be careful about wording, as 'reform is a function in REBOL. :-) 
all it has to do, is allocate more space. Just imagine a cramped 
desk and you want to put some things on the desk. Which is faster? 
Is it to remove one item at a time from the desk to place a new one 
there, or just swipe the desk clean in one go in order to free all 
desk space immediately?

the code for a c# app is compiled into an intermediary psuedo code 
then interpreted by the CLR (Common language runtime)

generally you just want to reduce the cases where you need to allocate 
space. if you reduce the number of cases and that reduces the number 
of garbage collections needed and there is a greater guarantee that 
all the allocated space will be freed up. REBOL is good, but the 
garbage collector isn't super intelligent so it helps to simplify 
its work.

View is a bit different, because it hogs memory quite badly. You 
can do a few limited things there to speed up display, but not much 
in terms of helping GC.

btw, about your append question... no, append does not need to allocate 
memory at each call. each series has some space free, and when that's 
up, a bigger space is allocated, usually with 2x increments (until 
a certain size, then it's linear). however, the whole series needs 
to be copied when that happens. so, if you append 1000 times, it 
may happen just 2 or 3 times, but still, if you know the final size 
already, you can save a lot by just preallocating it.

cool, I think I used to suffer a little because if your try to open 
a recordSet in visual studio it creates a natural bottle-neck because 
some idiots might have bound controls - and it has to handle that. 
I had to do all my processing of data on a 'SQL disconnected basis' 
 know what I mean by that?

I will. Will there be something standard in R3 to say pull a csv 
file in to blocks?

read/lines is a start to turning CSV into blocks -- you get one block 
entry per record.

right , thanks I'll have a go with that. I'll save all these snipets 
and perhaps we could build a database how-to to put on the new users 
docs.

thanks for that Henrik I'll have a look! Sorry i need to sign-off 
for a while (wifes picking up new car) please carry the thread on 
without me I'll print it later - thanks one again.

I found Brett Handley's parse tutorial a big help: http://www.codeconscious.com/rebol/parse-tutorial.html

I regularly import CSV files into REBOL.

The only trick is that I insist they be tab-delimited rather than 
comma-delimited, and that none of the strings contain tabs. That 
way, we can be sure that tab occurs only as a field delimiter.
The code then is
   data-block: read /lines %csv-data-file.txt
   foreach record data-block [
        record: parse/all record to-string tab
        ....code to handle the 'record block
    ]


If you need to handle actual comma separated where strings can also 
contain commas, you'll need to tweak the parse.

Thanks so much Sunanda, a couple of my customers receive stock update 
files as csv's (I don't think we could get them to send tsv's ) but 
that will fill a requirement brilliantly. If I decide to move any 
more complex apps to Rebol I may need to wait till I can get R3/command, 
I believe that will give me odbc (for excel and access) imports etc.

I've learnt an awful lot over the past week! But I think one of the 
most profound lessons I've learnt,

I quote from one of the WIki guides on the language


 This is perhaps the most important single piece of advice when learning 
 REBOL for the first time: 

    forget the past. Forget what you 
 already know about programming.

    REBOL is different. If you know 
 other programming languages such as C or BASIC, and you expect to 
 program REBOL the same way, 

    then what you will get as a result 
 is C or BASIC. Nothing better. We've seen this happen many times. 
 courtesy of Wikibooks




Every function or data routine I've written this week, I have stepped 
back from and thought "that's the c# way of doing it!"


Rebol opens up wonderful ways of approaching software tasks - I think 
I'm just entering my second week of de-programming.

Sunanda: parse works with comma delimited if there is a comma in 
the fields, as long as the fields are delimited by " when this happens.

>> parse/all {one,two,"three with a , inside",four} ","
== ["one" "two" "three with a , inside" "four"]

Thanks Gabriele -- that may work for SteveT.

However, there are some anomalies in the way parse handles RFC4180 
formatted CSV files. Particularly if there are embedded double quotes 
in a field.


For my purposes, I find tab delimited files are better -- though 
still not always perfect:

    >> x: parse/all {"a"^- ","","} to-string tab

    == ["a" { ","","}]   ;; 2nd field should be {,",}  -- result is close 
    enough that it can be tidied into that
 
   >> y: parse/all {"a", ","","} ","
    == ["a" { "} "" ""]    ;; 2nd field mashed irrecoverable!

Hi Gabriele, that's a good point, I've read the above articles about 
parse and there's an awful lot to learn to use it effectivly in REBOL.

exactly. this problem will go away in VID3 for R3. VID is very sparse 
with features like this and you've hit that wall now, a wall I've 
been climbing for years by doing things like LIST-VIEW and vid-field.r. 
:-)

a problem is that a lot of these internals are not documented and 
so they are very hard to figure out. I think it's safe to say this 
is the biggest sore point about REBOL, one we're anxious to not only 
fix but to turn completely around on and become a leader with.

I know some of my old colleagues would have a tick list before they 
would attempt any language/system and i think VID fails badly there. 
I can cope with it cos I'm so into Rebol, but I know others would 
find say Python with vxWidgets would tick more of their boxes!  Sorry 
for swearing (Python) ;-)

I'm usually a night owl. I went to bed at 3 am and I got up at 11 
am.

Are a lot of the other guys in the US? It's interesting to see where 
were all spread - hink Ashley is anitpadean Tes?

I think we're mostly US and European, but we have a few easterners 
as well.

Cool, is Ashley re-working rebGUI for VID 3 or will it be redundant. 
I've never bean totally happy with a third party widgets (like Python 
+ vxWidgets) or Java + Mattisse etc

I had a go with Ruby and vxWidgerts - it really put me off

Can a style include events?

yes, you can manipulate the events for a style with the FEEL object.

Yes, you can trap and handle in your own way all of the events a 
field style can receive.

Thanks Henrik , I'll have a go with that today.

Anton's made a version that has undo/redo, right?

You can copy the code from the default engage function, but you will 
fall into a trap; some of the words used in the default engage handler 
are bound to specific contexts. Your code will bind all the words 
in your context or global context. I'm talking about the words focal-face 
(which is in system/view), unlight-text, highlight-start, highlight-end 
and edit-text (which are in ctx-text).

probably a good idea to learn about bindings first to know what it 
means :-)

My edit-panel style is actually based on PANEL style, but pretty 
much supplants AREA, if you're happy with monospace font. (I haven't 
supported a single-line FIELD-like style, but could be easily done 
I expect.)

One other funcionality I'm missing is to be able to set the tab order 
! They won't always be the presented order.
And wether CR should act a sTAB or not.

whether CR can act as tab can be determined with a face flag.

A very handy shortcut.

I knew all this was possible, and I know a lot of people prefer things 
at this level to cover their own requirement.


But, returning to my original point. To make Rebol more general use 
- we need standard behaviour like this at a highr level?

So with the 'all'  'exit' combination you are handling any events 
(keypresses) you like in a form of 'switch' ?

if all the following conditions are true:
	- the act (action, same 
as event/type) = 'key (and not 'down, 'up mouse presses etc.)
	- 
the event/key = tab (the tab character)
then:
	focus a face
	exit

I've inserted that at the top of the function body, so if we handle 
the tab char key event, then we exit and it doesn't have a chance 
to be handled by the rest of the default code (which actually calls 
upon the large edit-text function from ctx-text to handle key events).

(Note that the above example where I set 'body is a bit "polluting". 
It sets the 'body word global. It's not strictly necessary, you can 
just replace body/2 with second second :engage. I just added it to 
make the meaning clearer.)

I wondered if the Rebol versions ended up becoming a lower-level 
parse.

Yes, on a particular field I want to control what the user can and 
can't enter

Yeah I was trying to approach it with ( if chars < 6 allow it ) which 
got me in a mess.

I'm sorry for all these questions - It sounds like I want you to 
do my work for me! I don't maind having to figure some things out 
myself . But I was asked to present waht I found difficult from a 
newbie point of view.

you're lucky to have us around, otherwise some of this would take 
a long time to figure out. I was frustrated for a long time about 
many of these things.

bindings are actually simply tieing a word to a list of words (a 
context), which is an object. outside the context, the word has no 
meaning, yet it can appear anywhere in code

I believe this is how local words work in a function definition. 
the words don't work outside the function, because they are bound 
to its context.

yes, by using the BIND function, you can bind a word to one or more 
contexts simultaneously.

yet it can appear anywhere in code

 <--- actually that's a bit wrong. if the word is not defined for 
 a particular context, then of course it's useless there. but if you 
 use the word in the right context, for example inside an object in 
 which it was originally created, then it will have meaning.

or more revealing:

>> source context

context: func [

    "Defines a unique (underived) object." 

    blk [block!] "Object variables and values."

][

    make object! blk

]

it's all just a big re-dress of objects. :-)

Think I get it - It's the object oriented side of Rebol - you could 
say that bind is a sort of inheritance ?

Yes, MS always partly implemented OO in VS. they didn't think there 
users could handle them !  Java is more of a full OO implementation 
but I find you end up having to override most objects and that's 
not good for code re-use.

This should be instructive. Type this into the console a line at 
a time:

I first show two different ways of creating an object, and then I 
show two different ways of getting a word in an object.

I got a halt-view near my-word?

Maybe you missed one of the single-quotes before a 'my-word (which 
makes it a lit-word!)

Each word carries its binding with it. ie. a reference to an object. 
(or no object if it is unbound).

An object is a container of word -> value pairs. When you ask for 
a word's value, the word's binding is checked to get the object.

A word isn't really a binding target, so you can't bind a word to 
itself (or any other word.)

(BIND accepts a known-word argument. It is the *object* that the 
known-word is from, not the known-word itself, which is the target 
for the bind.)

Yeah your mind get comfortable one way or the other - takes a lot 
of breaking

Hi Gregg, yes I've used it a lot with refinements. Like I said I 
think French or Spanish speakers will think in the same order as 
Rebol ;-\

Henrik: I believe that Rebol does have real inheritance, it's just 
based on protoytpes not classes:

>> a: make object! [b: func[][print "I'm from object a"]]
>> c: make a []
>> c/b
I'm from object a
>> d: make a [e: func [][print "I'm an extension to a"]] 
>> d/e
I'm an extension to a
>> f: make d [b: func [][print "I'm not the one in a"]]
>> f/b
I'm not the one in a

This even gives an inefficent way of extending an object:

>> a: make object! [b: func[][print "I'm from object a"]]
>> a: make a [c: func[][print "My new method"]]
>> a/b
I'm from object a
>> a/c
My new method

Hi All, In a list you have the 'first mylist/picked'  is this not 
available for 'choice' ?

Journal of a 'Newbie' by SteveT
-------------------------------------------

Hi all, second week of using Rebol. had to travel to London this 
week so you guy's have had less 'Noise' from me ;-/


Had some good help off Anton/Henrik with regard to trapping key-presses. 
I'm hoping that some of the properties (refinements) missing from 
R2 will be in R3 - things like forcing case..


I'm getting to grips with 'PARSE'  will be great if the proposed 
lecture comes off.


Still struggling with 'BIND' but  I think I've learned enough about 
PARSE, BIND, CONTEXT & DIALECTS, to start using some of these facilities 
in some apps.  Biggest lesson so far this week has been 'Don't use 
it just because it's there!'  Stepping back from some of the things 
I've tried have lead me to simplifying my app rather than achieving 
a complicated solution!

Happy trails...
SteveT

Hi Henrik, sure do! I've found that it's easy to step into one of 
the 'deeper' Rebol pools - say 'dialects' and thrash around not getting 
anything done in a disire to understand. This week I'm trying to 
learn just enough to do what I have on the drawing-board.

Hi all, I couldn't resist!  I just had to dip my toe into VID 3. 
It's like waiting for Christmas ;-) All those goodies! 


I've posted a snipet on my blog.     http://swt1962.spaces.live.com

Regards
SteveT

Some notes for your blog post:

'effects' are now 'options'

 - the idea is here to remove the need for face hacking. Options is 
 a clean, self documentable  way to alter the settings for a specific 
 style. But here, the fact that we can alter the appearance of the 
 style is a bit of a fluke, because we wanted a simple way to test 
 options. Originally it was the idea that altering any such effects 
 parameters directly in your layout would be prohibited; The style 
 would take care of this internally and you'd use specific button 
 types that would then use a specific style. You would use buttons 
 defined through its purpose rather than its appearance. You'd have 
 zero control over the appearance of the button, because that is controlled 
 by the style alone.


I know that sounds a little terrifying, but VID3 is meant to lift 
styling to a whole different level; You don't style every single 
face. You focus on the contents of your UI, and the purpose of each 
element, rather than its appearance and VID3 works out how to display 
it. This is for multiple reasons:


- VID3 can display on other devices than bitmapped displays, such 
as text consoles or vectored output.

- Styling becomes the job of one or more dedicated developers rather 
than the application developer, which standardizes styling. It makes 
it much simpler to build very large applications and it becomes possible 
to switch consistently between different styles, where one won't 
look crappy while another one looks great. They'll work equally well. 
Compare it to VID which is just the Wild West of styling. :-)

- Abstraction will make it possible to identify parts of a user interface, 
such as allowing VID3 to, on its own, find the cancel button in a 
window or automatically put key focus on the correct button for great 
consistency.


So when you, in your user interface design say: "I want a button 
that shows importance", you don't try to make a red button. You could 
use the 'warning-button style (just an example, doesn't exist yet). 
Similarly there will be styles for ok-button, cancel-button, etc. 
They are not called red-button, yellow-button, but are purely purpose 
oriented styles.


So while VID3 may look like just a prettier VID with resizing in 
a one-button example, it's actually a whole different beast. :-)

Thanks Henrik, so VID 3 will expect us to prepare our components 
or have some already prepared that we can then use - a bit like creating 
a'skin'. This is much better than 'hacking' each button or box in 
the middle of your layout. Eg, On my main menu example I could have 
my 'reflected image button' already pre-defined in my stylize section? 
Would you like me to post your clarification on my blog?

Hi Pekr,  I understand that, in Visual Studio I would create my own 
'custom' controls for various lookups or effect - that can be re-used 
through-out. If I am planning a full-blown application I would create 
the same tools. As I read thru the VID User Guide - I'm just playing 
with one-liners etc.

I think VID 3 will be useful for an app I will be doing later this 
year where I want to offer access to data in a consistant interface 
for desktop, web and windows mobile.

I think I spotted mention of a 'Windows Mobile'  plug-in the other 
day?

Henrik - to your post. It really sounds a bit terrifying, like old 
Win 3.1 visaul basic style ;-) I am really scared that I will see 
OK-button, Cancel-button and such styles. If I will see a pictogram 
on it, then really - we are going 10 years back - old design imo 
....

you will not stop ppl to add those pictograms. I did not say anything 
about a requirement :-)

Hi Henrik, just wanted a feel for where R3 will end up GUI wise. 
If in twelve months we end up with bells and whistles then cool - 
an app I've been asked to re-write needs to be very 'plush' so I'm 
going to have to use something else.

Hi Petr, It's a background project for me, clients in no mad rush, 
but will expect me to come up with the  goods within twelve months 
- they also want desktop & web. it's an interactive availability/booking 
system for group of hotels.

Jounal of a Newbie - by SteveT

Back on my travels again now (having to do paid work! ;-/  


Have learn't an awful lot about Rebol this month. Managed to get 
a good prototype reasonably functional. Have finsished my little 
licence maker app for internal use. Our client records believe it 
or not were just on Excel!! (Mrs T ) likes Excel! So i've created 
the same data in a simple client app using Henriks List-View and 
RebDB. Perfect for our internal use.


Going to try to learn more about Rebol3 (VID3) during February (Clients 
permiting !)

Steve

Hi all, can Rebol load XML structures straight into a block ?????

You can with my RebXML found here:
http://home.tiscali.dk/john.niclasen/rebxml/


The script xml2rebxml.r read an XML structure into a block with content 
defined in the spec:
http://home.tiscali.dk/john.niclasen/rebxml/rebxml-spec.html

'parse-xml is a standard REBOL function in 'core that does some basic 
XML processing. It may be enough for you.

I use Gavin's XML-parse functions every day:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=xml-parse.r

Not tried John's yet :-)

PARSE-XML is a built-in func as well. Not as complete as Gavin's, 
but works well for basic things. The biggest mod I've made to it 
is to swap the order of element value and attributes in the resulting 
block. That way you can address the value using path notation or 
SELECT. Working with attributes takes a little more work.

So for anyone new to REBOL or more generally to Forth (being one 
of the inspirations behind REBOL) I'd like to strongly recommend 
reading Leo Brodie's Thinking Forth - free PDF here - http://thinking-forth.sourceforge.net/


I stumbled across this group of programming books http://prog21.dadgum.com/19.html
and it reminded me I had meant to do some reading on Forth.  I'm 
now a third of the way through the Thinking Forth book kicking myself 
for not having dug into this earlier.  Just like learning about the 
functional perspective with Lisp and Erlang this reading is expanding 
my programming perspective with every chapter.  In addition to being 
valuable in the REBOL context it is simply a great book on programming 
in any context.

Whoa.  Elizabeth has posted a much nicer reprint on the forth.com 
site.    http://www.forth.com/starting-forth/
Nice!