| # | User | Message | Date |
| 2637 | Paul | Best thing to do is try it out as it really takes very little time to setup and try and you will know probably if it is suitable for you in about 10 minutes. | Tue 3:12 |
| 2636 | amacleod | What I would need is a simple method to sync them | Tue 3:12 |
| 2635 | amacleod | That was one of the things that had me thinking of using it. | Tue 3:12 |
| 2634 | Paul | It might work for that. Can also do the images conversion for you in REBOL format which is nice. | Tue 3:11 |
| 2633 | amacleod | I'm using mysql for the online component but I need a local storage method too for offline use | Tue 3:10 |
| 2632 | Paul | But not finished. | Tue 3:10 |
| 2631 | Paul | The next version of TRETBASE which is in work is multi-user and supports indexing. | Tue 3:10 |
| 2630 | Paul | It might work for you if you not in need of multi-user (simultaenous access) | Tue 3:09 |
| 2629 | Paul | Well, TRETBASE 1.0 is the only finished product right now. So the only available TRETBASE app is 1.0 which is really not a multi-user solution. | Tue 3:09 |
| 2628 | amacleod | Photos and diagrams will also be stored. | Tue 3:09 |
| 2627 | amacleod | So I can index for keywords and search and read only thse sections I need. | Tue 3:08 |
| 2626 | amacleod | I want to hold each section in a seperate database record | Tue 3:07 |
| 2625 | amacleod | I'm converting them to text and reformatting them to parse | Tue 3:07 |
| 2624 | amacleod | I trying to put a set of Fire department related materials online. THey are now in pdf | Tue 3:07 |
| 2623 | Paul | k | Tue 3:06 |
| 2622 | amacleod | Let me briefly explain where I'm going to see if you think its workable or perhaps a there is a better solution | Tue 3:05 |
| 2621 | Paul | Excellent choise ;-) | Tue 3:04 |
| 2620 | amacleod | Paul, while you are there... I was considering using Tretbase for this project | Tue 3:04 |
| 2619 | Paul | Ahhh yes that gets a bit more complicated. | Tue 3:04 |
| 2618 | amacleod | Yes and formating may need to be retained | Tue 3:04 |
| 2617 | Paul | Or do you mean a multiline might looks something like this: 2.1 Hello Goodbye Where the second line doesn't have the preceeding number? | Tue 3:03 |
| 2616 | Paul | So even if something is multiline you would still want each line of the multiline correct? | Tue 3:02 |
| 2615 | amacleod | I thought it would be a simple thing that I was missing. I may need to re-think the formatting of the document. | Tue 2:59 |
| 2614 | amacleod | Well it gets a little more complicated. some parts of the docment will be multilined. | Tue 2:58 |
| 2613 | Paul | So you just want each line then really? | Tue 2:57 |
| 2612 | amacleod | It need not be included in hte same copy just as long as I can record it. | Tue 2:56 |
| 2611 | amacleod | No I have a text document with section numbers in front: 2. Hello 2.1 Hello Again 2.1.1 Hello already 3. Goodbye I want the section number inclued in hte copy | Tue 2:55 |
| 2610 | Brock | he was looking for the number and the string though. | Tue 2:55 |
| 2609 | Paul | Something like that? | Tue 2:53 |
| 2608 | Paul | >> str: "193920347REBOL ROCKS!^/" == "193920347REBOL ROCKS!^/" >> parse str compose [some (charset "0123456789") text: copy text thru newline] == true >> text == "REBOL ROCKS!^/" | Tue 2:53 |
| 2607 | Graham | and correct syntax helps :) | Tue 2:51 |
| 2606 | Graham | non-digits: complement digit parse [ copy digit-text to non-digits copy text to newline skip ] | Tue 2:48 |
| 2605 | Graham | or | Tue 2:47 |
| 2604 | amacleod | I'll try that Graham. Thanks | Tue 2:45 |
| 2603 | Paul | yeah can't use set then. | Tue 2:44 |
| 2602 | Graham | He's using string parsing .. not block parsing | Tue 2:43 |
| 2601 | Graham | rule: [ copy d thru digits .... ] | Tue 2:43 |
| 2600 | Paul | you can always do something like set n number! | Tue 2:43 |
| 2599 | amacleod | Right. Anyway to capture the digit? | Tue 2:42 |
| 2598 | Graham | past the digit | Tue 2:42 |
| 2597 | Graham | because it matches digit and the cursor moves on | Tue 2:42 |
| 2596 | Graham | nope | Tue 2:42 |
| 2595 | amacleod | Graham, the digit String would be included in the copied text with this? | Tue 2:41 |
| 2594 | Graham | digits: [ some digit ] rule: [ digits ... ] | Tue 2:41 |
| 2593 | Graham | rule: [ digit copy text to newline skip ] parse stuff [ some rule ] | Tue 2:40 |
| 2592 | Paul | no it wouldn't | Tue 2:40 |
| 2591 | amacleod | So to newline does not include the newline? | Tue 2:40 |
| 2590 | amacleod | No | Tue 2:39 |
| 2589 | Paul | to goes to the point and thru includes the point | Tue 2:39 |
| 2588 | Graham | is this block parsing? | Tue 2:39 |
| 2587 | Paul | yes | Tue 2:39 |
| 2586 | amacleod | Is there a difference between using "to" and "thru" | Tue 2:39 |
| 2585 | Brock | Not as easy as it seemed to be. Will take more time than I have right now. | Tue 2:34 |
| 2584 | Brock | would it not simply be.... to some digit instead of what you have above? I'll start playing around and see if I can be of any help (if you haven't already figured it out) | Tue 2:23 |
| 2583 | amacleod | I'm trying to copy some text from the position found iwhile parsing a document.
I'm using something like: rule: [some digit copy text to newline] (--where "digit has ben defined as all digits 0 to 9) This copies eveerything after the digit. How would I copy the digit itself as well? | Tue 2:05 |
| 2582 | Anton | No worries. | 7-Jun 16:00 |
| 2581 | Josh | Thanks for the input. I will have to play around with those later as I am trying to get this finished up and then I can go back and clean up the code. The data is minimal enough for the script to finish in under a second anyway. Parse is pretty sweet. Makes this much neater than the alternative | 6-Jun 18:54 |
| 2580 | Anton | Josh, using the REMOVE-EACH very often is what makes your parse slow. A remove operation in the middle of a large string is slow, and you are doing many removes. That's why the others suggested using copy. | 4-Jun 11:59 |
| 2579 | Chris | Result is a little like: from -- <tag attr="attribute">Content</tag> to -- <tag> /attr attribute "Content" | 4-Jun 1:02 |
| 2578 | Chris | I've been toying with this to obtain a very parsable "dialect" -- my goal being to scrape live game updates from a certain sports web site (for personal use, natch). It's reliant on 'parse-xml though, so ymmv.... do http://www.ross-gill.com/r/scrape.r probe load-xml some-xml | 4-Jun 0:59 |
| 2577 | Geomol | If you wanna use PARSE, you can do something like: parse your-data [some ["<" thru ">" | copy y to "<" (if "" <> trim y [print y])]] | 3-Jun 20:57 |
| 2576 | Geomol | Josh, if you do a load/markup on the whole string, you get a block with tags and strings. You can then pick the string from the block, maybe doing TRIM on them to sort out newlines and spaces. Like: blk: load/markup your-data foreach f blk [if all [string? f "" <> trim f] [print f]] | 3-Jun 20:53 |
| 2575 | Brock | wouldn't you use "copy y " instead of "y:"? | 3-Jun 19:20 |
| 2574 | Josh | I came up with a rule: [some [thru "<td" thru ">" y: to "</td>" (a: remove-each tag load/markup y [tag? tag])]] but it seems to not be as efficient as it could be. | 3-Jun 19:09 |
| 2573 | Josh | with the </tr> at the end | 3-Jun 18:37 |
| 2572 | Josh | <tr style='mso-yfti-irow:6;mso-row-margin-left:.18%;mso-row-margin-right:20.4%'> <td style='mso-cell-special:placeholder;border:none;padding:0in 0in 0in 0in' width="0%"><p class='MsoNormal'> </td> <td width="23%" colspan=2 style='width:23.6%;padding:0in 0in 0in 0in'> <p class=MsoNormal><span style='font-family:"Lucida Sans Unicode"'> MNDLDA09Mar03a_e<o:p></o:p></span></p> </td> | 3-Jun 18:37 |
| 2571 | Josh | Here is some data: | 3-Jun 18:36 |
| 2570 | Josh | I'm finally digging into parse now, but I have a question about HTML. Big idea: pulling the data out of an HTML table (made in Word--ugh!). Where I am stuck: Is there a way to create a rule for opening tags such as <tr> that include a lot of formatting: i.e. <tr style="mso........> ? I want to pull the info inbetween the opening and closing tags. | 3-Jun 18:33 |
| 2569 | Anton | Right, that makes sense. | 20-May 17:45 |
| 2568 | BrianH | I mean you can do open/lines/direct and stream - then you would only need the memory for one line and a state machine. | 19-May 18:48 |
| 2567 | Chris | That would suck -- I use it. Seems like a common enough scenario.... | 18-May 1:54 |
| 2566 | Gregg | I think the string parsing behavior might go away in R3 Chris. Without support for other types as well, not many people seem to use it. | 18-May 0:54 |
| 2565 | Anton | BrianH, eh? read/lines would still try to read the whole document wouldn't it ? Or are you just suggesting that as a way which is then easily modified to allow larger than memory documents? | 17-May 15:12 |
| 2564 | Chris | String parsing too: parse "1234" [integer!] == true | 17-May 13:35 |
| 2563 | PeterWood | ..but only for values between -2**31 to 2**31 -1 >> parse [1] [integer!] == true >> parse reduce [2147483647] [integer!] == true >> parse reduce [2147483648] [integer!] == false | 17-May 4:46 |
| 2562 | Chris | Reminder: [integer!] is shorthand for [some digit] : ) | 17-May 1:36 |
| 2561 | BrianH | Well, at least the only way that doesn't rely on deep magic :) | 16-May 21:03 |
| 2560 | BrianH | If you are making your decisions on a per-line basis, you might consider doing a read/lines and parsing each line individually, maintaining your own state to tell you where you are in the greater document. It's the only way to parse documents greater than memory in size. | 16-May 21:02 |
| 2559 | amacleod | I'll play with this . Thanks | 16-May 21:00 |
| 2558 | BrianH | Yup. | 16-May 21:00 |
| 2557 | amacleod | sorry that is the level:? | 16-May 21:00 |
| 2556 | amacleod | This will give me a hit on any section or sub or sub sub? I may want to do something different depending on each. does this allow me to ? | 16-May 20:59 |
| 2555 | BrianH | section: [some digits (level: 1) [some ["." some digits (level: level + 1)] | "."]] | 16-May 20:57 |
| 2554 | BrianH | But I made a mistake. | 16-May 20:57 |
| 2553 | BrianH | Note that I did the longer alternate first. | 16-May 20:56 |
| 2552 | BrianH | section: [some digits (level: 1) ["." some digits (level: level + 1) | "."]] | 16-May 20:56 |
| 2551 | amacleod | How does parse evaluate the rule and document? does it check each rule through the whle doc or line first then goes back and checks with hte next alternate? and so on? | 16-May 20:56 |
| 2550 | BrianH | Yes, or combine them (which I will demonstrate). | 16-May 20:54 |
| 2549 | amacleod | so check sub-sub-sections then sub-section then sections in that order? | 16-May 20:54 |
| 2548 | BrianH | It checks the alternates (sections separated by | ) in order. If there is ambiguity, the way to get it to go for the longest match is to check for that match first. | 16-May 20:53 |
| 2547 | amacleod | longer matches... This is where I get lost in parse. What do you mean? | 16-May 20:51 |
| 2546 | amacleod | in the above code the following will work:
format_section: [copy rest to newline (print reduce [rest ]) but this fails: format_section: [copy sec section copy rest to newline (print reduce [sec rest]) | 16-May 20:50 |
| 2545 | BrianH | Well, first of all you need to put the longer matches first in your alternates, so they will be tested first. | 16-May 20:49 |
| 2544 | amacleod | THE docs come from pdf's that I have converted to text and tried to reformat by hand to hte similest form whilepreserving the structure of the doc. In addition to sections, sub-sections and sub-sub-seections there are nubered lists, letter lists, photos/diagrams, and tables to deal with. I thought I start with sorting out the sections and tackle the rest later. | 16-May 20:47 |
| 2543 | BrianH | Are you creating the documents or are others doing so? For that matter, does it just go to 3 levels of numbers? | 16-May 20:44 |
| 2542 | amacleod | I thought you ment the document heading... No reason but my rules account for it. The rules work in simpler tests.. | 16-May 20:43 |
| 2541 | BrianH | Actually, the inconsistency affects the parse rules. I ask again... | 16-May 20:41 |
| 2540 | amacleod | BrianH, sorry BRian the text above is just from a random and simpler section of the document. if I copied the from the begining the first line would not have a number at all. | 16-May 20:39 |
| 2539 | BrianH | Any reason that the headings with one number have a trailing period and the rest don't? | 16-May 20:38 |
| 2538 | amacleod | If I use format_section code directly with parse it works but i get nothing when I redirect it to another line. THe above code is similar to what Carl used in his text to html script. | 16-May 20:37 |
| 2537 | amacleod | space: charset " ^-"
spaces: [some space]
chars: complement charset " ^-^/"
digit: charset "0123456789"
digits: [some digit]
section: [digits "." some space]
sub-sec: [digits "." digits spaces]
sub-sub-sec: [digits "." digits "." digits spaces] rules: [heading some parts done] (where heading is the first line of the text file] parts: [newline | section format_section | sub-section | sub-sub-section] format_section: copy sec section copy rest to newline (print reduce [sec rest]) | 16-May 20:35 |
| 2536 | amacleod | 3. CONSTRUCTION OF PORTABLE ALUMINUM LADDERS 3.1 Aluminum ladders are divided into two basic types of construction, viz:, solid beam and truss. 3.1.1 Solid Beam Aluminum Construction- This type of ladder has a solid side rail construction with aluminum rungs connecting with the side rails at fourteen inch intervals. The connection is generally either by a welded joint between rung and side rails, or by an expansion plug pinching the rung tightly to the side rails and internal backup plates. (Figure 2 A) 3.1.2 Aluminum Truss Construction- In the aluminum truss design, the top and bottom rails are connected to rung assemblies or rung blocks by rivets. The rungs are either welded or expansion plugged to the rung plate assemblies, which are supported by the top and bottom rails. (Figure 2B) 3.2 The base of the portable aluminum ladder is provided with either steel spikes or swiveling rubber safety shoes and aluminum spikes. For ladders equipped with the swiveling device, the rubber pads should be utilized when the ladder is to be raised and used on hard surfaces. (Figure 2A, 2B) 3. CONSTRUCTION OF PORTABLE ALUMINUM LADDERS | 16-May 20:30 |
| 2535 | amacleod | Oldes, thanks for your suggestion. It works when I do a simple one line rule as you suggested but when I try to use multiple rules it fails. Example of what I'm trying to do: Example of the text document: | 16-May 20:30 |
| 2534 | Chris | Don't want to add too much, but with parse you can really build up a vocubulary based on the patterns you know: section: [integer! ["." | 1 4 ["." integer!]]] ; -- or whatever rule covers all permutations chars-sp: charset " " space: [some chars-sp] parse/all [copy sn section space [to newline | to end]] Vocabularies are easy to wrap in their own context too. Note also that [integer!] is a shorthand for [some digit] -- very useful : ) | 16-May 14:55 |
| 2533 | BrianH | not -> note | 16-May 13:53 |
| 2532 | BrianH | Look up recursive descent parsing, and take a not of the difference between left recursion and right recursion. | 16-May 13:52 |
| 2531 | BrianH | If the section numbers always end with a period, you can do this: some [some digits "."] If the section numbers don't end with period you can do this: some digits any ["." some digits] | 16-May 13:48 |
| 2530 | Oldes | or something like that: ch_digits: charset "0123456789" r_section: [pos1: some [some ch_digits opt #"."] pos2: (section: copy/part pos1 pos2)] parse/all "2.3.4 line" [r_section copy rest to end] probe reduce [section rest] ;== ["2.3.4" " line"] | 15-May 19:30 |
| 2529 | Oldes | ch_section: charset "0123456789." parse/all "2.1.3 line" [copy section some ch_section copy rest to end] probe reduce [section rest] ;== ["2.1.3" " line"] | 15-May 19:25 |
| 2528 | amacleod | I've got rules to find each: (some digit "." some space) etc. and it works. I've been able to copy the text following with (copy text thru end) but how do I copy the section number? | 15-May 19:14 |
| 2527 | amacleod | Most lines begin with a section number (2.), or a sub-section (2.3) or a sub-sub-section (2.3.5). | 15-May 19:11 |
| 2526 | amacleod | I'm trying to parse a tex document that I've formated into lines of text with blank lines between simialr to make doc format | 15-May 19:09 |
| 2525 | amacleod | I'm just not getting the hang of parsing. I've read tutorials an looked at scripts but when I try to adapt it to my work it fails. | 15-May 19:08 |
| 2524 | Henrik | the function is recursive, so that may put a twist on b). I forgot that detail with BIND on a) so thanks for that. c) seems to work best. | 12-May 6:46 |
| 2523 | Chris | When it comes to complex rules, I opt for b). At that, I'd go for context [] where there are a lot of associated words... | 12-May 1:15 |
| 2522 | Chris | Assuming you want to assign values to function locals from the external parse rules, you can a) bind as you are doing, b) create a larger context for the function encompassing your rules or c) compile the parse rule, either on creation of the function or for each instance. a) rule: [set tag tag!] test: func [data /local tag][bind rule 'data parse data rule tag] b) test: use [tag][ rule: [set tag tag!] func [data][parse data rule tag] ] c) rule: [set tag tag!] test: func [data /local tag] compose/only [parse data (rule) tag] Also, note that when you bind, it alters the original block -- no need to reassign to a new word. | 12-May 1:14 |
| 2521 | Henrik | the five last lines in the function are the important ones. | 11-May 18:52 |
| 2520 | Henrik | set 'html-gen func [ "Low level HTML dialect" data [none! string! tag! url! number! time! date! get-word! word! block!] /local cmd blk header row-blk start-tag dr tr pr wr ] [ if get-word? data [data: get data] if any [url? data string? data number? data word? data time? data date? data] [out data return true] if none? data [return true] dr: bind data-rules 'data ; this is the easiest way? can we not bind directly in the parse block? tr: bind tag-rules 'data pr: bind page-rules 'data wr: bind word-rules 'data parse data [any [cmd: [dr | tr | pr | wr]]] ] | 11-May 18:52 |
| 2519 | Henrik | if I have a rule-block that does not exist in the same context as the main parse block, is there a simple way to rebind it without composing it into the main parse block? my current solution is to bind it to a temp block and use the temp block as a rule in the main parse block, which is less than optimal, I think. | 11-May 18:50 |
| 2518 | Henrik | yep, works | 28-Apr 15:04 |
| 2517 | Oldes | >> parse to-block load "<" [_less] == true | 28-Apr 15:03 |
| 2516 | Henrik | nice, thanks | 28-Apr 15:03 |
| 2515 | Oldes | I'm using help words like: slash: to-lit-word first [/] dslash: to-lit-word "//" rShift: to-lit-word ">>" UrShift: to-lit-word ">>>" _greater: to-lit-word ">" _less: to-lit-word "<" _noteql: to-lit-word "<>" _lesseql: to-lit-word "<=" _greatereql: to-lit-word ">=" | 28-Apr 15:02 |
| 2514 | Henrik | (note this block can only be made without a space at the end in rebol 2.7) | 28-Apr 15:01 |
| 2513 | Henrik | >> parse [>] [>]
== false
>> parse [>] ['>]
** Syntax Error: Invalid word -- '> How do you parse that block? | 28-Apr 15:00 |
| 2512 | Oldes | I should probably not to use the code evaluation so much directly in the parse rule block and rather call a function if I need a lot of temp variables to process the action. | 17-Mar 17:11 |
| 2511 | BrianH | Wait, USE may not copy in R2 - that could be even worse. | 17-Mar 16:59 |
| 2510 | BrianH | That kind of overhead is usually only worth it when you can't get rid of concurrent use any other way. | 17-Mar 16:58 |
| 2509 | BrianH | Does a bind/copy on its code block every time it is used. | 17-Mar 16:56 |
| 2508 | Oldes | what about 'use tmp: 1 use [tmp][ parse "test" [copy tmp to end (probe tmp) ]] probe tmp | 17-Mar 16:55 |
| 2507 | Gregg | I often use contexts with parsers, to contain the rules. | 17-Mar 4:45 |
| 2506 | btiffin | context [ ] is just a shortcut for make object! [ ] and it's great. The more we hide in objects the easier it will be share, or at the least, easier to use code from a variety of developer sources. Programming in the Many is important in our context as there are relativily few of us in the "many" - so far. So when even our small stuff is shareable we all win. | 16-Mar 19:04 |
| 2505 | BrianH | The only execution overhead of context is when it is built - nothing extra at runtime. The memory overhead is minimal. Every word is defined in a context, even the global ones. Overall, using an object to wrap the temporary variables that your rules use is not a bad idea. As long as you are doing this to better manage your program and reduce the scope of errors, it is great. | 16-Mar 18:51 |
| 2504 | JohanAR | 2. I don't use alot of recursion so far. some [...] usually works equally well in my applications. But it's definitely a valid point, and I'll try to keep it in mind | 16-Mar 18:47 |
| 2503 | JohanAR | 1. Hide them from myself :) I don't mind having lots of global variables in a small script, but I really don't like it in larger programs. To keep things well organized I prefer if variables aren't valid in a larger context than necessary, to avoid overwriting, accidental use etc. Does context [ ... ] add alot of overhead btw? Maybe I should try to use that more often | 16-Mar 18:43 |
| 2502 | BrianH | 1: Hide them from whom, and why?
In general, if you want to hide something about your parse rules, you need to hide the parse rules altogether. That is not to say that it is a good idea; I've found that in most cases that someone wants to hide some code or variables in REBOL, they really want to do something else and the something else depends on the circumstances. What do you hope to accomplish? 2: You have to be careful with temporary variables. REBOL parse rules are often recursive, and the temporary variables used with them are not. You have to be extra careful to not recurse to another trip through the same parse rule before you are done with the temporary variables in the first round, or put off setting the temps until just before they are used. It's not as hard as it sounds. | 16-Mar 14:58 |
| 2501 | JohanAR | I think my parse rules use lots of temporary variables.. How do you prefer to hide these? | 16-Mar 14:02 |
| 2500 | BrianH | ["test" '| 1 1 123] | 6-Mar 20:23 |
| 2499 | JohanAR | damnit, found out already.. | was apparently a word! :D | 6-Mar 20:23 |
| 2498 | JohanAR | is it possible to write a parse rule that accepts something like [ "test" | 123 ] ? | 6-Mar 20:22 |
| 2497 | Paul | I have already got a solution for TRETBASE. | 6-Mar 18:25 |
| 2496 | BrianH | That is the table spec, right? Not the row data? | 6-Mar 18:25 |
| 2495 | Paul | Brian, in my TRETBASE for example when a new table is created then one must set the fields and their datatypes such as: ["fname" string! "lname" string! "age" integer!] but it will always be a format of [string! datatype! string datatype!....] | 6-Mar 18:23 |
| 2494 | BrianH | generated per row -> generated rule per row | 6-Mar 18:06 |
| 2493 | BrianH | If you are doing type specifications to validate records, the fastest way to do it is to generate static validation rules based on the specification, then just apply the generated per row. Static validation rules would be faster than dynamic. | 6-Mar 18:06 |
| 2492 | BrianH | This assumes that you aren't taking advantage of REBOL's type system to do SQLite-style manifest typing. | 6-Mar 18:03 |
| 2491 | BrianH | I'm a little curious as to why you need to have the datatype of a field referenced in the record at all, if you are just using the REBOL data model. Wouldn't the data itself have a type? It seems to me that specified datatypes of fields would only need to be specified once per table. | 6-Mar 18:01 |
| 2490 | Paul | I'm not worried about the coding, I'm concerned about the performance. If I have to parse a million records or something then anything that cuts down on the amount of evaluation is necessary. | 6-Mar 17:57 |
| 2489 | BrianH | You could write a script to generate the rules. It could be faster than writing them directly. | 6-Mar 16:44 |
| 2488 | Gregg | "So setting types to all of those is not very efficient." -- Do you mean in the parsing, or in the time it takes to set up the rule(s)? | 6-Mar 16:35 |
| 2487 | Paul | Right now I have a solution in place for the database and have decided to continue to allow the types to be inputted. The pro outweight the cons in my opinion with my application. | 5-Mar 23:27 |
| 2486 | BrianH | Right now, the only thing that is protecting REBOL from serialized functions and objects is the fact that their bindings are not deserialized properly. Small blessings, I guess. In the meantime, screen your data. | 5-Mar 19:00 |
| 2485 | BrianH | You should probably exclude function types from your acceptable types to store in your database, as well as library! and a few others. | 5-Mar 18:57 |
| 2484 | BrianH | We have already put together a set of requests to enhance PARSE. This problem could be solved by at least 3 of them. | 5-Mar 18:55 |
| 2483 | Paul | So my next question is if we were to wish for something to be added to REBOL to make this task easier and submit it to RAMBO what would be the best way to describe what is desired? | 5-Mar 18:10 |
| 2482 | Paul | So setting types to all of those is not very efficient. At this point using parse to do this is as Gregg said not "simple.. | 5-Mar 18:09 |
| 2481 | Paul | Hi Ingo, I'm planning on supporting most of the REBOL datatypes which is very long when you consider that REBOL has 54 of them. | 5-Mar 18:08 |
| 2480 | Paul | Henrik, pretty much all of them. | 5-Mar 18:01 |
| 2479 | Gregg | I'm with Ingo on this. And as far as "being simple", this isn't really. :-) When I've needed to parse for datatypes, I either reduce/compose or set up rules for the types. | 5-Mar 17:42 |
| 2478 | Ingo | I know it's already been beaten to death, but I guess you don't want to support all of rebols datatypes, so what is wrong with listing them explicitly? >> types: ['string! | 'integer! ] == ['string! | 'integer!] >> data: ["age" integer! "name" string!] == ["age" integer! "name" string!] >> data2: ["age" integer! "name" string! "gobbledygook" object!] == ["age" integer! "name" string! "gobbledygook" object!] >> parse data [some [string! types]] == true >> parse data2 [some [string! types]] == false | 5-Mar 17:11 |
| 2477 | btiffin | Yeah, but ... :) | 5-Mar 15:42 |
| 2476 | Henrik | or just act on words in your dialect :-) | 5-Mar 15:31 |
| 2475 | btiffin | Gee, I guess to be secure you need reduce/only exclude query system/words [integer! string! ...] | 5-Mar 15:30 |
| 2474 | Henrik | evaluating words can still be unsafe | 5-Mar 15:25 |
| 2473 | btiffin | reduce/only is safe for that no? | 5-Mar 15:22 |
| 2472 | Henrik | well, he doesn't like the serialization syntax and he won't reduce which is a security problem (always wise though) | 5-Mar 15:21 |
| 2471 | btiffin | Or yes, if the source is reduced. parse reduce ["age" integer!] [string! set type #[datatype! datatype!] (print ['got type 'type? type? type])] | 5-Mar 15:17 |
| 2470 | btiffin | Or not. :) | 5-Mar 15:10 |
| 2469 | btiffin | Sorry, try [#[datatype! datatype!] that should restrict the match to only datatype values. | 5-Mar 15:09 |
| 2468 | Henrik | I'd still not bother with it :-) how many datatypes will you support? | 5-Mar 14:45 |
| 2467 | Paul | But that doesn't fill a rule block to be passed to parse which is my original intention but is still very useful. | 5-Mar 14:41 |
| 2466 | Paul | drop the [word!] requirement from the argument and report true or false. | 5-Mar 14:40 |
| 2465 | Paul | dlt-type?: func [w] [found? any [attempt [to-datatype w] false]] | 5-Mar 14:39 |
| 2464 | Paul | More like this for my needs: | 5-Mar 14:39 |
| 2463 | Paul | similiar anyway | 5-Mar 14:36 |
| 2462 | Paul | Yeah which is what I use now. | 5-Mar 14:36 |
| 2461 | Henrik | or perhaps: dlt-type?: func [w [word!]] [any [attempt [to-datatype w] false]] | 5-Mar 14:35 |
| 2460 | Paul | dlt-type?: func [w [word!]][ foreach item datatypes [if equal? to-word item w [return true]] false ] | 5-Mar 14:33 |
| 2459 | Paul | Maybe something like this is best solution: | 5-Mar 14:33 |
| 2458 | Henrik | the serialized syntax _is_ the solution to that problem. yes the syntax is a bit more cumbersome. | 5-Mar 14:24 |
| 2457 | Henrik | dialects are separate language domains where the normal rules of REBOL syntax don't necessarily apply.... about lit-type, then you need lit-object, lit-none, lit-whatever :-) | 5-Mar 14:24 |
| 2456 | Paul | except that this isn't exactly what I think of as being "lit" as we know it. | 5-Mar 14:23 |
| 2455 | Paul | Would be nice to have something that simply says lit-type? | 5-Mar 14:23 |
| 2454 | Henrik | that means: if your datatype requires some level of serialization syntax to work, just consider them words. | 5-Mar 14:21 |
| 2453 | Paul | lol | 5-Mar 14:21 |
| 2452 | Henrik | woah, that was nonsense: "dialects are words" I meant "dialects consists of words and a few other things" | 5-Mar 14:20 |
| 2451 | Henrik | all datatype words are stored in the 'datatypes word | 5-Mar 14:20 |
| 2450 | Henrik | put weight in that dialects are words and if you take advantage of that, your dialect will become simpler | 5-Mar 14:19 |
| 2449 | Paul | Yeah I even looked into going thru system/words and collecting all the datatype but the method I deployed was smaller and more effective. | 5-Mar 14:19 |
| 2448 | Henrik | well, if that's all you do, you don't even have to convert it to a datatype, IMHO. it's enough to collect a list of rebol's datatypes as words, so they be used to trigger on the input word which looks like a datatype. I can see you are going for correctness, i.e. wanting the input to be a real datatype, but if you only use that input as a trigger to do something, you don't need to convert it to a real datatype. just operate using words. | 5-Mar 14:17 |
| 2447 | Paul | Uses the mold/all method you provided yesterday. | 5-Mar 14:11 |
| 2446 | Paul | then this: data: head data unless parse data [some [string! datatype!]][return "Syntax Error!"] | 5-Mar 14:10 |
| 2445 | Paul | Currently, I do something similiar to this: user passes dynamic data captures in a block: data: ["fname" string! "age" integer!] Then I do the following: data: next data forskip data 2 [poke data 1 load mold/all attempt [to-datatype data/1]] | 5-Mar 14:10 |
| 2444 | Paul | I currently have resorted to a different approach. | 5-Mar 14:08 |
| 2443 | Henrik | parse data ['string! (do-this) | 'integer (do-that)] | 5-Mar 14:08 |
| 2442 | Paul | Yes, I understand that but it defeats Carl's famous philosophy which is that simple things should be simple to do. | 5-Mar 14:08 |
| 2441 | Henrik | you can also simply parse each single word like that. you can be as exact as you want in the parser. | 5-Mar 14:07 |
| 2440 | Paul | Henrik that was the problem I almost had to resort to. But hopefully you see the problem. We should come up with ANOTHER method for handling this problem that is more seemless. | 5-Mar 14:07 |
| 2439 | Henrik | well, how do you want it to automatically recognize the input as datatypes? the only other way around it is to keep them as words and make a datatype rule to detect words that look like a datatype. | 5-Mar 14:06 |
| 2438 | Paul | Brian here is a problem with your stradegy: >> parse [1][set n #[datatype! any-type!]] == true Notice it returns true for the actual values that meet the datatype. Which is what I don't want. I need to know SPECIFICALLY if what was passed was integer! or string! or whatever. | 5-Mar 14:05 |
| 2437 | Paul | Henrik that is ugly way to approach it. I feel were lacking a "better means" to handle this problem. | 5-Mar 14:03 |
| 2436 | btiffin | Henrik's original hint and any-type! should catch them. parse ["age" integer! "loc" string!] [string! set the-type #[datatype! any-type!] (print ["got an " the-type]) string! #[datatype! any-type!]] | 5-Mar 13:41 |
| 2435 | Henrik | one way to deal with that would be to make your form so that it would not be possible to enter the data in a different way than the intended format, but that requires more form design of course. | 5-Mar 13:33 |
| 2434 | Paul | The datatype entered will vary. | 5-Mar 12:33 |
| 2433 | Paul | They input a string followed by a datatype. For example: ["age" integer! "location" string!] | 5-Mar 12:32 |
| 2432 | Henrik | Paul :-) | 5-Mar 10:03 |
| 2431 | Henrik | Pail, what exactly does the user input in the field? | 5-Mar 10:02 |
| 2430 | Paul | I can see where we need to add this capability to REBOL. | 4-Mar 23:30 |
| 2429 | Paul | In my situation the lit-word and the mold/all methods are not ideal. | 4-Mar 21:33 |
| 2428 | Paul | Yes, thanks Brian. | 4-Mar 21:30 |
| 2427 | BrianH | Keep in mind that you can parse for 'string! (the lit-word version of the word string!) and that will match without reducing. | 4-Mar 21:23 |
| 2426 | Henrik | no problem | 4-Mar 21:05 |
| 2425 | Paul | Thanks Henrik. | 4-Mar 21:04 |
| 2424 | Paul | I think I have a way around that. | 4-Mar 21:04 |
| 2423 | Paul | But it helps to know that as it gives me more options | 4-Mar 21:03 |
| 2422 | Paul | I'm gonna have to work on this a bit - still seems like a cumbersome way | 4-Mar 21:03 |
| 2421 | Paul | Remember you don't know what is in the block as it might not be string!. | 4-Mar 21:02 |
| 2420 | Henrik | that depends entirely on how you build the block | 4-Mar 21:02 |
| 2419 | Paul | what if they just enter a field and that field is translated as a block as [string!] | 4-Mar 21:02 |
| 2418 | Henrik | >> type? first head insert [] string! == datatype! | 4-Mar 21:02 |
| 2417 | Henrik | if you insert the right datatype in the string with code, the datatype should be recognized automatically. the other syntax is for manual entry. | 4-Mar 21:01 |
| 2416 | Paul | Hmmm this still might be a problem though. Because serialization is good if you know to put that into the block yourself but how to you take dynamic data that is user inputed and serialize the datatype that is in it? | 4-Mar 21:00 |
| 2415 | Paul | :) | 4-Mar 20:58 |
| 2414 | Henrik | I'm sure it will :-) | 4-Mar 20:57 |
| 2413 | Paul | It's gonna help me for what I'm doing. | 4-Mar 20:57 |
| 2412 | Paul | Yes greatly | 4-Mar 20:56 |
| 2411 | Paul | yeah I knew that one but didn't think about that for datatypes. | 4-Mar 20:56 |
| 2410 | Henrik | a great and valuable tool (also speeds some things up) | 4-Mar 20:56 |
| 2409 | Henrik | >> type? first [none] == word! >> type? first [#[none]] == none! | 4-Mar 20:56 |
| 2408 | Paul | yeah I see which is exactly what I'm looking for. | 4-Mar 20:56 |
| 2407 | Henrik | mold/all will display how to serialize something so you don't need to reduce a block to get the right datatype in there. | 4-Mar 20:55 |
| 2406 | Paul | nice. | 4-Mar 20:55 |
| 2405 | Henrik | your "lit-datatype" is actually serialization. it exists for everything that otherwise would lose its datatype inside a block | 4-Mar 20:54 |
| 2404 | Paul | I think that could work | 4-Mar 20:54 |
| 2403 | Paul | cool Henrik | 4-Mar 20:54 |
| 2402 | Paul | didn't know mold/all did that for string! | 4-Mar 20:54 |
| 2401 | Henrik | >> mold/all string! == "#[datatype! string!]" >> blk: ["something" #[datatype! string!]] == ["something" string!] >> type? second blk == datatype! ; voila :-) | 4-Mar 20:53 |
| 2400 | Paul | But I still need to validate the passed block | 4-Mar 20:53 |
| 2399 | Paul | I dont' want any execution of code as I don't know what might be passed by the user | 4-Mar 20:53 |
| 2398 | Paul | What I'm trying to avoid is any reducing | 4-Mar 20:52 |
| 2397 | Paul | yes Henrik | 4-Mar 20:52 |
| 2396 | Paul | I guess you mean datatype! with the "!" | 4-Mar 20:52 |
| 2395 | Henrik | >> blk: ["something" string!] == ["something" string!] >> type? second blk == word! >> type? second reduce blk == datatype! ; this you know, right? OK... | 4-Mar 20:52 |
| 2394 | Paul | >> parse ["something" #[datatype string!]] [string! datatype!] ** Syntax Error: Invalid construct -- #[ ** Near: (line 1) parse ["something" #[datatype string!]] [string! datatype!] | 4-Mar 20:51 |
| 2393 | Paul | I don't get what you mean by serialized state | 4-Mar 20:50 |
| 2392 | Henrik | same if you use none or other things that would be considered words in an unreduced block. | 4-Mar 20:49 |
| 2391 | Henrik | string! is considered a word here. you must provide the datatype in its serialized state: parse ["something" #[datatype string!]] [string! datatype!] | 4-Mar 20:49 |
| 2390 | Paul | be nice if there was a lit-type! | 4-Mar 20:41 |
| 2389 | Paul | I see I can do a reduce on the blk when passed to parse and get it true but not sure that is safe for my situation. | 4-Mar 20:29 |
| 2388 | Paul | how do you do this: blk: ["somestring" string!] We can't do: parse blk [string! datatype!] and get a match. | 4-Mar 20:15 |
| 2387 | Paul | shouldn't datatype! be included in rule block parsing? | 4-Mar 20:06 |
| 2386 | JohanAR | Ahh, another block around the into statement did the trick :P Thanks for the help though parse data ['table some [ into [ some [ set n integer! (print n) ] (print "-") ] ] ] | 2-Mar 19:22 |
| 2385 | JohanAR | just found out that this seems to work, but I don't really see why I have to include end. As I've understood "into" is supposed to fail and continue if the next item isn't a block! parse data ['table some into [ end | some [ set n integer! (print n) ] (print "-") ] ] | 2-Mar 19:19 |
| 2384 | Graham | do you need an 'end ? | 2-Mar 19:06 |
| 2383 | JohanAR | Can anyone help me why the following appears to work, but still returns false? data: [ table [1 2 3] [4 5 6] ] parse data ['table some into [ some [ set n integer! (print n) ] (print "-")] ] | 2-Mar 18:51 |
| 2382 | BrianH | Cleaner yet. | 23-Feb 17:50 |
| 2381 | BrianH | replace/all form [a b c d e f] " " "-" | 23-Feb 17:49 |
| 2380 | PatrickP61 | I was just wondering about the trailing dash, but thought that could be handled in a different step. Your method is cleaner. | 23-Feb 17:47 |
| 2379 | BrianH | You have to remember to structure your rules using LL style. Do you notice that I checked for one word first, then looped over the subsequent words? That was to avoid putting the "-" after the last word as well. Parse uses right recursion - not like yacc, which uses left recursion. | 23-Feb 17:45 |
| 2378 | PatrickP61 | Super -- Thanks for the info. I'm still learning about parse! | 23-Feb 17:41 |
| 2377 | BrianH | Patrick, in answer to your first question: parse [a b c d e f] [ set x word! (prin form x) any [set x word! (prin join "-" form x)] ] | 23-Feb 17:41 |
| 2376 | PatrickP61 | Now that I think of it, I would not even use a parse to do that. But what could I do if I wanted only a subset of characters to show up without defining them all | 23-Feb 17:19 |
| 2375 | PatrickP61 | I have a question on the above parse by Oldes on Feb 8th. If you feed in a [a b c d e f] you will get a-b-c-==false How can you change the parse so that it will put a dash in between all characters, without defining each character? | 23-Feb 17:16 |
| 2374 | Geomol | Robert, there's no emulator written in REBOL, that can run Elite, afaik. But there are emulators emulating the BBC computer, if that's what you mean, and they can run Elite. I use an emulator called BeebEm3. | 8-Feb 18:27 |
| 2373 | Henrik | beautiful, thanks | 8-Feb 14:28 |
| 2372 | Oldes | a: func [v] [ parse v [ any [ [ 'a (prin "a") | 'b (prin "b") | 'c (prin "c") ] (prin "-") ] ] ] | 8-Feb 14:23 |
| 2371 | Oldes | a: func [v] [ parse v [ any [ [ 'a (prin "a") | ['b (prin "b")] | ['c (prin "c")] ] (prin "-") ] ] ] | 8-Feb 14:22 |
| 2370 | Henrik | I'm a little stuck here with a simple problem: a: func [v] [ parse v [ any [ 'a (prin "a") | 'b (prin "b") | 'c (prin "c") (prin "-") ] ] ] >> a [a b c c a] abc-c-a I want to print the dash after every letter. Do I have to include it after each word? | 8-Feb 13:24 |
| 2369 | Robert | Is there an emulator for this Elite release? | 8-Feb 11:55 |
| 2368 | Gregg | /at is probably fine. | 6-Feb 17:05 |
| 2367 | Geomol | Yes! :) From http://www.bbcmicrogames.com/acornsoft.html "It has been ported to just about every other platform out there however, it appeared first on the BBC." The BBC had a 6502 too, and it's the platform, I'm testing up against, so let's hope, it all work out well. | 6-Feb 10:26 |
| 2366 | Graham | Elite was done on the C64 as well as other computers of that era, so would have been done in 6502 assembler. | 5-Feb 23:33 |
| 2365 | btiffin | /skip would be the rebolious name I think, but /org would resonate with me as well. | 5-Feb 22:02 |
| 2364 | Geomol | Or I should just stick with /at, because that's the word, we usually use to position ourselves within a series. (And the ram can be seen as a series.) | 5-Feb 21:50 |
| 2363 | Geomol | /begin maybe? | 5-Feb 21:46 |
| 2362 | Geomol | So it could be named something like: /pc /target /address /start ... | 5-Feb 21:44 |
| 2361 | Geomol | The Program Counter get set to the argument for that refinement, else 1, if the refinement isn't there. | 5-Feb 21:43 |
| 2360 | Geomol | The asm6502 can take the refinement /at to tell the starting address in the 64kb ram area for the produced code. I don't like the refinement being called /at, because we already have the word AT. Any suggestions for a better name? | 5-Feb 21:42 |
| 2359 | Geomol | btiffin, hehe :) | 5-Feb 21:28 |
| 2358 | Geomol | Instructions can be separated by : on the same line, and comments put at the end. Example: asm6502 "inx:iny This is a comment!" UPPER/lower case can be used: asm6502 "INX : INY This is a comment!" | 5-Feb 21:28 |
| 2357 | btiffin | Elite, John. Elite. | 5-Feb 21:27 |
| 2356 | Geomol | It's about 10k REBOL source. 2644 bytes compressed. It amuses me to use REBOL for things like this. The most enjoyable language around! It took me like 3 halves evenings. | 5-Feb 21:18 |
| 2355 | Gregg | I haven't played with it, but it's still veyr impressive for such a short project. | 5-Feb 21:15 |
| 2354 | Geomol | It's a one pass assembler and then some. After first pass, it checks, if there is forward referencing to labels and then fix those relative addresses directly in the produced code. Should be fast, as it's not a completely two-pass. | 5-Feb 21:14 |
| 2353 | Geomol | Yes, for the syntax errors it's fixed now: http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r For labels not found, you have to search you source, where you branch to that label. | 5-Feb 21:11 |
| 2352 | Gregg | Since it's line-based, could the syntax error tell you which line, in addition to what op it's near? | 5-Feb 21:00 |
| 2351 | btiffin | Agreed; write a line, test a line. Personal comment: Then forget you wrote it so a few days later you can write a line, test a line and then go "whoa, deja-vu" :) | 5-Feb 19:50 |
| 2350 | Geomol | I've found, that it's best to test while I develop. It's traditionally design-programming-test. I don't find this the best way, if you want fast progress and few errors. | 5-Feb 19:46 |
| 2349 | Geomol | You see, now I have a 6502 assembler written in REBOL, so now it will be easy for me to test a 6502 emulator, while I'm writing it. | 5-Feb 19:44 |
| 2348 | Geomol | Yeah, I'm only a level 1multitasker or so. | 5-Feb 19:42 |
| 2347 | Graham | single stepping? | 5-Feb 19:41 |
| 2346 | Geomol | One step at a time! | 5-Feb 19:41 |
| 2345 | Graham | Oh ...I thought we were going to see a 6502 emulator! | 5-Feb 19:40 |
| 2344 | Geomol | :) | 5-Feb 19:35 |
| 2343 | btiffin | Go John Go! | 5-Feb 19:34 |
| 2342 | Geomol | I finished v. 1.0.0 of 6502 assembler: http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r It defines the asm6502 function, which take 6502 assembler as text input and produces 6502 machine code (opcodes). Might be a good example of parsing in REBOL. | 5-Feb 19:27 |
| 2341 | Pekr | But weeee want RebCode. Hopefully it comes. Even if slower than R2 version. We will see - maybe C based plug-ins and proper porting efforts have more sense, dunno ... | 4-Feb 20:38 |
| 2340 | Carl | In R3 variables are more protected than in R2. But, perhaps we can do something with temporaries on stack that require fewer tests, but have limited usage patterns. | 4-Feb 20:31 |
| 2339 | Carl | So... the trick in RebCode for using it in R3 is how to efficiently access variables. | 4-Feb 20:30 |
| 2338 | Geomol | I'm on the parsing assembler part, so no rebcode yet here. | 4-Feb 19:59 |