World: r3wp
[I'm new] Ask any question, and a helpful person will try to answer.
older newer | first last |
amacleod 16-Jan-2008 [1048] | I'm using your experience with rebol to inspire a friend at work. He's shown some interest but I think your the look of your app will impress him. |
Gregg 16-Jan-2008 [1049] | Very cool indeed Steve! Man, I feel like a slow learner now. ;-) |
james_nak 16-Jan-2008 [1050] | I think Steve should move out of the "I'm New" section. Nice app. |
SteveT 17-Jan-2008 [1051x4] | ========================================================= Perspectives of a newbie! By Steve Thornton (SteveT) Hi everyone, just got up and running this morning (think I've found a bug in Vista when used on dual-screen Doh!!) Thanks for everyones very kind comments on my main menu. I'm learning masses about Rebol (mainly due to hours of reading - and you guy's), I think I will be a 'newbie' for quite some time though! While I love databases and user interface design (yep I literaly have sat at customers watching how they work! ;-) I know 'get a life!' ) I have no formal computer science education so I'm weak on some of the theoretical stuff. We don't all nead to know the theory of how search engines etc work, as long as they work! I look at some of the code in the messages on here and think OMG, what a load of scientific formulae that is ! :-/ I think an overview of some of the 'heavy' stuff would help some of us to get the most from Rebol, perhaps some of you 'heavy' guy's/gal's could 'volunteer' to post an article on their particular forte. One last thing... I have a table that holds several bits of [optional] data .. tax ref, employer, vat no etc.. and also a flag that the user can set as to wether that field is to be displayed. Can I use the following structure? Or am I asking for trouble? Table... DETAILS [dRec dRef [dTitle d1] [dTaxref d2] [dVatno d3] [dEmployer d4]] I think I just heard Henrik tutting! :-0 By for now |
The code for my reflected icons is below (with icon). It's nearly right just need to get rid of some jaggies. Just load any 72x72 icon you want to display. | |
image image-logo %your-pic.png main: layout [ box 72x72 image-logo [alert "You've clicked!" ] feel [over: func [face act pos] [ face/size: either act [82x82][72x72] show face ref/size: either act [82x50][72x40] show ref helper/text: either act ["Click me now!"]["Highlight an icon"] show helper ] ] below ref: box image-logo 72x40 effect [gradcol 0x1 0.0.0 80.80.80 flip 0x1 fit blur] below helper: text "Highlight an icon" silver / 1.5 ] main/size: 150x200 main/effect: [gradient 0x-1 0.0.0 120.120.120] view/new main do-events | |
Sorry first line should be image image-logo load %your-pic.png | |
BrianH 17-Jan-2008 [1055x2] | Steve, the standard way to signify optional values in REBOL is the none value - you can use it like the null value in SQL. If you are not reducing your records you can write none as #[none]. The ANY function is like the SQL COALESCE function. |
If you want to do keyword-based records, put the keywords and values in the same block and use select/skip data key 2 Put each record in its own block: with variable length records you will need to track the end of the record otherwise. This method will be slower, but take less space when at least half of the fields are usually missing. | |
SteveT 17-Jan-2008 [1057] | Thanks Brian, I've noticed a lot of examples use 'reducing' |
BrianH 17-Jan-2008 [1058x3] | In general, fixed-length records with none for missing values is the fastest and easiest. |
It gets easier in R3, where the behavior of some standard functions has been changed to be more in keeping with the none-means-missing-data principle. For now you have pick, find, select, and all of the conditionals. | |
In R3 you add the ordinals (first, second, ...) and the map! type to that collection. | |
SteveT 17-Jan-2008 [1061] | Cool , in SQL et al , null can be useful for finding where say a JOIN has no corresponding RIGHT side. |
SteveT 19-Jan-2008 [1062] | Hi all, is there an EASY way of changing this :- [ fld1 fld2 fld3 fld4 fld1 fld2 fld3 fld4 ] into this [ [fld1 fld2 fld3 fld4] [ fld1 fld2 fld3 fld4 ] ] Thanks Steve |
Sunanda 19-Jan-2008 [1063] | 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] ] |
SteveT 19-Jan-2008 [1064] | 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! |
Henrik 19-Jan-2008 [1065x2] | if you are willing to, it may be possible to manipulate the block itself, but I think it's slower. otherwise make sure you allocate the necessary space for newblock. that makes garbage collection easier for REBOL. |
newblock: make block! divide length? oldblock 4 | |
SteveT 19-Jan-2008 [1067x3] | is that faster than Sunandas foreach? |
4 being the number of elements in each row ( So that must be known!) If you don't know how many elements (columns) could that be achieved using the newl-line? ? | |
sorry new-line? | |
Henrik 19-Jan-2008 [1070x2] | 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. | |
SteveT 19-Jan-2008 [1072] | How fast is REBOL in processing this (I know it's processor/memory dependent) but could you manage say 100,000 rows ? |
Henrik 19-Jan-2008 [1073x3] | 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 ] |
100000 is easy | |
but... it's a good idea to study some things here about which loop functions are faster than others. | |
SteveT 19-Jan-2008 [1076] | great - I don't think anything I would pull thru would contain more than 100,000 rows x 15 cols |
Sunanda 19-Jan-2008 [1077] | 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] ] |
Henrik 19-Jan-2008 [1078x2] | some functions can give simple code, but are slower, because they are mezzanines based on other loops. |
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 | |
Sunanda 19-Jan-2008 [1080x2] | You could do an easy timing test by creating some test data: loop 1000000 [append oldblock random/secure "abcdefghijklm"] |
....My computer took about a second to reformat the test data. Fast enough? | |
SteveT 19-Jan-2008 [1082] | Brilliant, thanks Sunanda. you guys answer questiions faster than I can ask them ;-) |
Henrik 19-Jan-2008 [1083x2] | you can explore this yourself by studying the source for various loop functions. http://www.hmkdesign.dk/rebol/files/385cc7420409fa08f768a537a52ce4d8-76.html That blog post might be of help. |
be aware that pretty code is not always fast, even in REBOL. :-) | |
Sunanda 19-Jan-2008 [1085] | Thanks Henrik for the append vs insert optimization too! |
SteveT 19-Jan-2008 [1086] | 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 |
Henrik 19-Jan-2008 [1087x2] | one thing that amazes me is that PARSE is very fast, despite being one of the most complicated functions to understand in REBOL. if you learn how to use it, it can perform some quite amazing tasks. |
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. | |
SteveT 19-Jan-2008 [1089x4] | Yes I've only used it for my licence creator applet - I't's one of the core items I need to master. At the moment I'm trying to get blocks/series to fit into recursions I have created in legacy apps |
I don't mind re-learning these for R3, I thnk I need to learn R2 to master R3 | |
sorry this wireless keyboard has a stutter ;-) | |
So the immediate thing I've picked up is as you use append Rebol has to re-form the block on each iteration! Is that right? | |
Henrik 19-Jan-2008 [1093x2] | 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? | |
SteveT 19-Jan-2008 [1095] | The processing seem's amazing compared to say one of my c# apps. |
Henrik 19-Jan-2008 [1096] | yes, and they say interpreted languages are slow, right? :-) |
SteveT 19-Jan-2008 [1097] | Yep sorry Henrik, I meant allocate more space |
older newer | first last |