| # | User | Message | Date |
| 20826 | Graham | so I just approached it by supplying a callback to format the directory | 13-Jan 20:31 |
| 20825 | BrianH | However, FTP directory listings are a different issue, protocol overhead that needa a lot of special-case code, as I recall. | 13-Jan 20:31 |
| 20824 | Graham | Anyway, ... we need some decisions made about the base context, network tracing etc | 13-Jan 20:30 |
| 20823 | Graham | So, the opportunity for code reuse was limited | 13-Jan 20:29 |
| 20822 | Graham | And it uses STAT instead of STOR for uploading files ... | 13-Jan 20:29 |
| 20821 | BrianH | In theory R3 schemes should just handle the protocol overhead and provide an abstracted behavior model, then the concrete work should be done in the handler or by the port actions. | 13-Jan 20:28 |
| 20820 | Graham | So, for hylafax which uses the ftp protocol ... I would have to rewrite the whole scheme because the ftp scheme assumed the directory listing was always in a certain format etc. | 13-Jan 20:28 |
| 20819 | Graham | having simple port abstractions helps the early user but is very limiting to experienced users | 13-Jan 20:27 |
| 20818 | Graham | My issue with the r2 schemes is that too much was abstracted so that you could not easily do stuff without rewriting the scheme | 13-Jan 20:26 |
| 20817 | BrianH | Right, thanks. | 13-Jan 20:26 |
| 20816 | Graham | off topic guys | 13-Jan 20:25 |
| 20815 | BrianH | I have AltME running on an SD card, so it's even slower, but the big problem is the sending lockups and network dropouts. Chat works so much better - AltME 3 can't come quickly enough for me. | 13-Jan 20:24 |
| 20814 | Pekr | eh, I am out from net in something like 30 minutes. The four star hotel charges 15 EUR for 100 minutes of wifi. That is stupid :-) When we do wifi, we suggest hotels to provide such service for free. | 13-Jan 20:23 |
| 20813 | Carl | Because they write state variable files constantly for the apps. | 13-Jan 20:21 |
| 20812 | BrianH | Pekr, I was going to work on the network scheme revamp after that. I have to put things I already know how to do first, and there are a few LOAD and module changes that have accumulated that I know how to do already. | 13-Jan 20:20 |
| 20811 | Pekr | both altme and IOS are not designed for USB. Strange, as altme does not have much files to read from (in comparison to IOS chat, where one msg = 1 file), but slow anyway ... | 13-Jan 20:19 |
| 20810 | Carl | For those countries, maybe next DevCon? | 13-Jan 20:19 |
| 20809 | Pekr | What do you know about those countries btw? ;-) You were supposed to - was to BrianH ... I have some 10-15 sec lag here ... | 13-Jan 20:17 |
| 20808 | Carl | Pekr, seems too slow for USB flash. I think it's on floppy or R/W CDROM. | 13-Jan 20:17 |
| 20807 | Carl | B: sounds good. | 13-Jan 20:16 |
| 20806 | Carl | (Romania) | 13-Jan 20:16 |
| 20805 | Carl | Pekr, do you mean rewamp? Are you sure you're not visiting Transylvania? | 13-Jan 20:15 |
| 20804 | BrianH | Carl, the design od that was finalized and the work will be done this week. | 13-Jan 20:13 |
| 20803 | Pekr | I thought it is slow because I run it from USB flash ... I am in Hungary on business trip for 3 days .... :-) | 13-Jan 20:13 |
| 20802 | Pekr | You were supposed to do the rewamp, no? :-) Now as Graham produces schemes, we will be lazy to redo it :-) | 13-Jan 20:13 |
| 20801 | Carl | I really think we need an EXPORT word that make exports easier to manage. Simple I think. | 13-Jan 20:12 |
| 20800 | Carl | Man this system is slow.... help! Let's move this puppy!... I mean world. | 13-Jan 20:12 |
| 20799 | Pekr | btw - were exports "finalized? Remember you posted blog about it. Ditto read/write topic (Prunning down the read/write blog ... and following talking about read/string) | 13-Jan 20:11 |
| 20798 | Carl | Also, for testing purposes... if you need to add a system/standard object, just unprotect and append to the object. I think the kernel will accept that. (But, do not reMAKE the standard object!) | 13-Jan 20:11 |
| 20797 | BrianH | The model is good, but most of the wrapper and helper code needs work, or revamping. | 13-Jan 20:10 |
| 20796 | Carl | Once we understand the exports, we can then formally define the module, title, export list, etc. | 13-Jan 20:09 |
| 20795 | Carl | In R3, you can create a module inline with one line of code. That's where to start. | 13-Jan 20:09 |
| 20794 | Carl | I would propose a Networking Module that can hold misc functions and variables, debugging modes, etc. | 13-Jan 20:08 |
| 20793 | Carl | Graham is corrrect. We need to finalize a base context for networking. | 13-Jan 20:07 |
| 20792 | Pekr | not overhaul of ports, but schemes. Ppl were thinking about FSM etc. | 13-Jan 20:07 |
| 20791 | Carl | The first thing people need to know is that THIS IS NOT R2! The first mistake is to approach ports the same as R2. That will not work here. | 13-Jan 20:06 |
| 20790 | Carl | Pekr, there is no "overhaul" of the approach. I spent several months on the new design, and it's much better than R2. There may be a few small tweaks to make and a few issues to consider, but other than that, it's quite good. | 13-Jan 20:05 |
| 20789 | Graham | Still need a place for set-net, network timeouts, email object .... commonly used parse rules and bitsets, network error handlers | 13-Jan 20:01 |
| 20788 | Pekr | UDP implementation? (Needed for dns:// scheme to work?) | 13-Jan 20:00 |
| 20787 | Graham | eg. write ftp://ftp.rebol.com/uploads %matrix.mov | 13-Jan 19:59 |
| 20786 | Pekr | current implementation is not what I thought is going to happen - the rehaul of aproach we are taking for schemes. Some ppl are also confused by read/write function names vs read, write event names, and IIRC Graham also noticed few other issues ... | 13-Jan 19:59 |
| 20785 | Pekr | there is one very usefull doc describing device communication (don't remember the name now), but stil some things are going to be missing ... | 13-Jan 19:58 |
| 20784 | Carl | As related to: http://www.rebol.net/wiki/Ports:_Synchronous_and_Asynchronous_Operations | 13-Jan 19:49 |
| 20783 | Carl | Ok, that's great. So, by "sync wrappers" you mean some kind of internal utility to deal with the sync/async differences when called from the user level? | 13-Jan 19:43 |
| 20782 | Graham | http://rebol.wik.is/Rebol3/Schemes | 13-Jan 19:39 |
| 20781 | Graham | Most need sync wrappers around them, and some actors to provide the previous way of doing things | 13-Jan 19:32 |
| 20780 | Graham | As mentioned in chat, most of the common schemes are now "done" | 13-Jan 19:31 |
| 20779 | Carl | How are things going on adding a few schemes? I mentioned that I would review the docs and add more examples; however, if someone has implemented a simple scheme example, like finger or such, then let's use that as the starting point, clean it up (if necessary), and put it on the wiki for others to learn from. | 13-Jan 19:28 |
| 20778 | Henrik | also serves as a security measure | 13-Jan 8:54 |
| 20777 | BrianH | Yeah, I picked up on that later Maxim :) | 13-Jan 8:50 |
| 20776 | Henrik | by tripping, I assume it means, if the parse somehow returns a function, that when run would cause an error, hence the get-word!. | 13-Jan 8:49 |
| 20775 | Maxim | in R3 it doesn't trip anymore which is what my post is about, the only place where :get-words have been usefull for me are for passing functions as values or to handle unset values. | 13-Jan 8:45 |
| 20774 | BrianH | Not always needed, but good for bulletproof code :) | 13-Jan 8:41 |
| 20773 | BrianH | Use :done so the error doesn't trip. | 13-Jan 8:40 |
| 20772 | Maxim | the disarmed state of error objects in R3 is REALLY cool... simplifies code and switches them to usefull data, which is an alien concept to most other languages. success?: all [ done: try [parse data rules] not error? done not string? done ] here strings are the return type for parse block created (syntax?) errors in the source data | 13-Jan 7:55 |
| 20771 | Graham | done => down. | 13-Jan 0:15 |
| 20770 | Graham | I've added a REBOL forum to my new vbulletin forum .. since reboltalk seems to be done http://synapse-ehr.com/forums/forumdisplay.php?3-Rebol | 13-Jan 0:15 |
| 20769 | Gabriele | Brian: pipe was not posted publicly, though, nothing that i know of is using it (i did it for Maarten but he didn't use it :), so at this point is a lone function in a lone file... given that it will need adaptation to work in R3, feel free to make a R3 version out of it. it would be hard to claim copyright on that even if I wanted to. ;) | 12-Jan 9:17 |
| 20768 | Graham | Seems to have worked .. managed to upload 32Mb using ftp | 12-Jan 9:04 |
| 20767 | BrianH | Check first, and remember to manage your buffers well. | 12-Jan 8:51 |
| 20766 | Graham | that being the case, I can just write 32,000 bytes each time there is a wrote event | 12-Jan 8:40 |
| 20765 | BrianH | And other tasks can still do their stuff, once we have those. | 12-Jan 8:25 |
| 20764 | BrianH | You can use async by providing a handler, or use one of the sync wrapper functions. If you use the sync wrappers it is still internally async, but not as far as you know. | 12-Jan 8:24 |
| 20763 | Henrik | BrianH, silly question, but where does the async nature of R3 ports then go, if writing blocks? | 12-Jan 8:22 |
| 20762 | BrianH | I would expect so, but you'd block your task! until it was done if you do it in one WRITE. And that means blocking quite a bit until tasks are properly working. | 12-Jan 8:20 |
| 20761 | BrianH | It is documented, as I recall, as part of the basic port model. | 12-Jan 8:18 |
| 20760 | Graham | If I write a 100Mb file to a tcp port ... does R3 automatically write it in chunks for me? | 12-Jan 8:18 |
| 20759 | Graham | Good to know | 12-Jan 8:16 |
| 20758 | BrianH | There are no series-like ports in R3. | 12-Jan 8:15 |
| 20757 | BrianH | All ports in R3 are like /direct ports in R2, autoadvancing with an internal position. | 12-Jan 8:14 |
| 20756 | Graham | If so, this seems to be the only documentation! | 12-Jan 8:02 |
| 20755 | Graham | Does the skip occur automatically on a file port? | 12-Jan 8:01 |
| 20754 | Graham | where is the skip occuring to advance thru the from-file? | 12-Jan 7:59 |
| 20753 | Graham | there's this example on http://www.rebol.net/wiki/Port_Examples copy-file: func [ "Copy a large file" from-file to-file /local file1 file2 data ] [ file1: open from-file file2: open/new to-file while [not empty? data: read/part file1 32000] [ write file2 data ] close file1 close file2 ] | 12-Jan 7:58 |
| 20752 | BrianH | CASE is used for that stuff a lot in the mezz code. | 11-Jan 20:05 |
| 20751 | Graham | ahh.. ok | 11-Jan 20:01 |
| 20750 | BrianH | case [any-function? :a [...] file? :a [...]] | 11-Jan 20:00 |
| 20749 | Graham | I guess I could use function! native! [ .... ] | 11-Jan 19:58 |
| 20748 | Graham | Nope .. then I have to check for native! | 11-Jan 19:56 |
| 20747 | BrianH | switch type?/word :a [... | 11-Jan 19:55 |
| 20746 | BrianH | Less overhead than TO-WORD too. | 11-Jan 19:55 |
| 20745 | Graham | that evaluates the function | 11-Jan 19:54 |
| 20744 | Henrik | ah yes, couldn't remember what the specific method was. | 11-Jan 19:54 |
| 20743 | BrianH | TYPE?/word is best for now - less overhead than the REDUCE method. | 11-Jan 19:54 |
| 20742 | Henrik | switch to-word type? a [... | 11-Jan 19:53 |
| 20741 | Graham | switch type? a reduce [ function! [ print "function" ] file! [ print "file" ] | 11-Jan 19:52 |
| 20740 | Graham | If I have a: :print or a: %file.txt how can I check for what it is ? switch type? a [ function! [ print "function" ] file! [ print "file" ] | 11-Jan 19:51 |
| 20739 | BrianH | No decision yet. It certainly will do for now. | 11-Jan 19:48 |
| 20738 | Graham | Has any decision been made to use Gab's rlp format for documentation and code generation yet ? | 11-Jan 19:25 |
| 20737 | Graham | Geez, if you gave me the host code, I'll probably end up in the science channel .... | 11-Jan 19:17 |
| 20736 | Pekr | we need Holger back, to finish networking :-) | 11-Jan 19:15 |
| 20735 | BrianH | Learn :) | 11-Jan 19:13 |
| 20734 | Graham | Heh .... and what would I do with it? lol | 11-Jan 19:05 |
| 20733 | BrianH | Ask and you'll have it too. The source for tcp:// is in it as well. | 11-Jan 19:03 |
| 20732 | Graham | Host code .. that's the one some guys have now? | 11-Jan 19:02 |
| 20731 | BrianH | And other fine schemes. | 11-Jan 19:00 |
| 20730 | Graham | Needed to do reverse dns lookups | 11-Jan 19:00 |
| 20729 | BrianH | UDP would be defined in the host code - if it's not there, it's not in R3 yet. | 11-Jan 18:59 |
| 20728 | BrianH | It's been hard to get enough spare time with a working brain. Too many emergencies lately that take up my time, mostly my sleep time. | 11-Jan 18:58 |
| 20727 | Graham | Where's UDP? | 11-Jan 18:57 |
| 20726 | BrianH | Not much yet - I'm still reviewing the lower levels. There are two levels below the http scheme: TCP and the port model. | 11-Jan 18:56 |
| 20725 | Fork | ^-- Actually, it need not keep you from writing (to-word type? foo) if it knew that datatypes should have the last ! chopped if turned into a word | 11-Jan 18:56 |
| 20724 | Graham | and what have you discovered? | 11-Jan 18:55 |
| 20723 | BrianH | Oh wait, that happened to me too. The http scheme doesn't handle server errors well, and the internet has been getting increasingly crappy lately. That's why I've been looking over the scheme lately. | 11-Jan 18:54 |
| 20722 | Graham | Steeve talked about using a dialect to write schemes .. to create the FSM needed ... weren't you also doing something along these lines as well? | 11-Jan 18:54 |
| 20721 | Graham | BrianH - crashed on windows 7 | 11-Jan 18:52 |
| 20720 | Fork | Regarding some of the above discussions of type?/word, I feel the confusing bit is that integer! the datatype and integer! the word probe identically. If the word was integer! and the datatype were integer!! (for instance) then it would prohibit you from writing (to-word type? foo) but at least you could tell what was going wrong in your switch, because it would tell you that integer!! wasn't defined as an actual word. You could still write (integer! = type? foo) in expressions. | 11-Jan 18:48 |
| 20719 | BrianH | Don't add proposed options either - we can add them when they become actual. The rebol.net wiki is the place to put proposals. | 11-Jan 18:40 |
| 20718 | BrianH | Actually, can you update it to remove all optioins not supported by R3? READ and WRITE are low-level functions in R3. | 11-Jan 18:38 |
| 20717 | Graham | The other refinements look wrong as well. | 11-Jan 18:37 |
| 20716 | BrianH | Cool. Does the READ doc have the same /binary option? | 11-Jan 18:37 |
| 20715 | Graham | updated 'write documentation to remove the /binary | 11-Jan 18:36 |
| 20714 | BrianH | And have you tried logging into the manual with your chat ID? | 11-Jan 18:34 |
| 20713 | Pekr | Graham - if you have sufficient R3 Chat ranking (IIRC 40), you can log-in and edit R3 Docs ... authentication database is shared ... | 11-Jan 18:34 |
| 20712 | BrianH | Which platform? | 11-Jan 18:33 |
| 20711 | Graham | before I crashed it with an invalid dataype error | 11-Jan 18:30 |
| 20710 | Graham | I was on last night | 11-Jan 18:30 |
| 20709 | BrianH | The manual uses the same login. | 11-Jan 18:29 |
| 20708 | BrianH | Are you on R3 chat? That is the first step in getting write access to the R3 manual wiki. | 11-Jan 18:26 |
| 20707 | Graham | It would help if someone updated the docs ... or gave us write access to the help/doc wiki | 11-Jan 18:18 |
| 20706 | Graham | An old time reboler like me still gets confused hence the question ... | 11-Jan 18:18 |
| 20705 | BrianH | Is it alright with you if we try to adapt PIPE? Has it been posted publicly? I remember seeing it but can't remember if it was private. | 11-Jan 14:57 |
| 20704 | BrianH | Gabriele, PIPE should definitely be included in R3, even if it's mezzanine. It would be worth it just to keep people from overloading READ with too much high-level crap. It would be mezzanine first in any case - we only convert functions to native once their behavior is agreed upon and we can say for sure that performance is worth it. | 11-Jan 14:34 |
| 20703 | BrianH | The basic function to load REBOL code is DO. Most types are constructed, not literal. Even the scoping is procedural. | 11-Jan 14:20 |
| 20702 | BrianH | No, LOAD doesn't execute code, and the point of MOLD is to generate executable code. LOAD/all does something different. | 11-Jan 14:16 |
| 20701 | sqlab | mold/all | 11-Jan 14:15 |
| 20700 | sqlab | I think load should be the match for mold, and load/all for mold7all | 11-Jan 14:14 |
| 20699 | BrianH | Or native!, op! or action! values. | 11-Jan 14:13 |
| 20698 | BrianH | R3 won't be fully serializable, even when the bugs are fixed. You won't be able to serialize handle!, command!, task! or module! values. | 11-Jan 14:12 |
| 20697 | BrianH | Pekr, the opposite of LOAD is MOLD/all, the opposite of DO is MOLD. MOLD doesn't generate serialized syntax. | 11-Jan 14:10 |
| 20696 | BrianH | Yes, but MOLD/all loses the procedural syntax that MOLD generates, so many types just don't work when loaded because of binding. | 11-Jan 14:08 |
| 20695 | Pekr | BrianH: what does it mean, that serialised syntax will be lost? I thought that we are closer to the state, when REBOL is going to be fully serialisable :-) | 11-Jan 14:06 |
| 20694 | sqlab | I just checked it. loading after a mold/all still gives the datatype! | 11-Jan 14:05 |
| 20693 | BrianH | There was a suggestion that SWITCH treat certain words as keywords, translating them to their standard values, in particular logic! and datatype! keywords. This would make SWITCH work like CONSTRUCT, and would likely require an /only refinement for the non-keyworded behavior like CONSTRUCT has. This would add a little overhead to SWITCH, but not as much as the workaround code already adds. The question hasn't yet been resolved, and should be brought up again for final resolution - some mezzanine code would need revising. | 11-Jan 14:04 |
| 20692 | sqlab | Do you use it during mold? I think you loose it thru load. | 11-Jan 14:04 |
| 20691 | BrianH | Pekr, "The cases can be any datatype" refers to the type of the values, not their value. The type of integer! is datatype!, the value is #[datatype! integer!]. You can use the serialized syntax if you want to specify dataype! values directly, but watch out: If your build process goes through a MOLD then the serialized syntax will be lost - this tripped me up when I was porting R2/Forward to the R2 mezzanine code, I had to rewrite TYPES-OF and TO-TYPESET. | 11-Jan 13:55 |
| 20690 | Pekr | ah, interesting .... | 11-Jan 13:38 |
| 20689 | sqlab | switch works with datatype!, if you use a datatype! (read a true datatype!) in the block. see switch type? %test.r [#[datatype! file!] [print "type file!"]] | 11-Jan 13:36 |
| 20688 | Rebolek | As Orbital said, "sad but true". Fixing docs is probably !1. | 11-Jan 13:23 |
| 20687 | Pekr | fixing docs as well ... | 11-Jan 13:22 |
| 20686 | Rebolek | Also I think that adding those five characters "/word" to your (or Graham's who asked initialy) code takesmuch less time than this discussion. | 11-Jan 13:19 |
| 20685 | Rebolek | Ah, ok, some kind of dialect - I'm not against it, if you design something and put it here I thing it will get some attention, it will be enhanced and it also may become part of Rx. But SWITCH uses "the only holy way" and that's good :) | 11-Jan 13:18 |
| 20684 | Pekr | Then there would not be need for type?/word ... | 11-Jan 13:16 |
| 20683 | Rebolek | ...why IT works... | 11-Jan 13:15 |
| 20682 | Pekr | no, you don't understand. It is just you understanding the only one holy way - submitting function a regular REBOL code :-) Whereas I was just wondering, with rather uniform design of switch (case followed by code to execute), if we could supply kind of dialect to switch function as a body. The same way as how we have 'secure, 'get-modes or other dialects ... | 11-Jan 13:15 |
| 20681 | Rebolek | I agree that it may look confusing to some people, same as: >> f: func [a][append [] a] >> f 1 == [1] >> f 2 == [1 2] But as I said, it's better to understand why works this way than dumbening the language just because newbies may be confused. | 11-Jan 13:15 |
| 20680 | Rebolek | What you want is that words that get evaluated to datatype! should be evaluated but other words shouldn't. That's inconsistent and for everyone trying REBOL is better to understand the difference between word! and it's value than otherwise. | 11-Jan 13:11 |
| 20679 | Pekr | It is difficult for me to explain, but - I thought, that 'switch case block could be treaded some other way internally. Not reduced, but in kind of "DELECT" or dialect kind of type. Then you could really write any datatype for the case ..... not sure it is doable nor neccessary, just thinking aloud ... | 11-Jan 13:07 |
| 20678 | Pekr | But - was switch always native? | 11-Jan 13:05 |
| 20677 | Pekr | I surely don't want all blocks being reduced. I think I know what you are talking about. But then let's stop claiming 'switch can accept any datatype for the case branching. It can't ... | 11-Jan 13:05 |
| 20676 | Rebolek | And that's wrong. And if people don't get it, they're free to use some other language. | 11-Jan 12:47 |
| 20675 | Rebolek | Pekr, you may be right about correcting docs, I'm not sure, haven't read them in a while. But in all other aspects you are wrong. What you want is basically same as what that crazy spammer on blog wanted few weeks ago. Blocks always reduced. | 11-Jan 12:46 |
| 20674 | Steeve | Pekr my friend, it was just a little tease :-) | 11-Jan 12:42 |
| 20673 | Pekr | It was Graham who actually asked, how is he supposed to handle datatype! datatype in 'switch function. If he was confused for a fraction of minute, then novices could be confused too. The function behaviour is inconsistent, at least in reference to docs, period. Even if I never used type?/word (as I don't work with dynamic code much), I used to-word type? value in 20 seconds, so I found may way around the "problem". Maybe now I understand, why some external ppl see REBOL community as bunch of "we are best, we know the best" luxury fools - we try to make idiots from ppl not actually as knowleable as some elite members. | 11-Jan 12:31 |
| 20672 | Steeve | Or maybe a new mezz would be good to have. Krenzelokize: func [bum this [block!]][ switch type?/word bum this ] | 11-Jan 12:18 |
| 20671 | Pekr | It might be usefull to add idiom like you mentioned to the end of examples? Now I at least know, what type?/word exists ... | 11-Jan 12:15 |
| 20670 | Pekr | "The cases can be any datatype" - is imo wrong, as it is not obviously true. You can't use datatype! type for the case. You have to convert it to word! type ... | 11-Jan 12:14 |
| 20669 | Steeve | i don't see anything wrong in the definition, but yeah, we could add some use cases | 11-Jan 12:13 |
| 20668 | Pekr | http://www.rebol.com/r3/docs/functions/switch.html .... or someone should correct docs so that this special case is more obvious ... | 11-Jan 12:11 |
| 20667 | Pekr | If the case can be ANY datatype, and it works with xy datatypes, there is no point into turning datatype! dtype into word first, no? | 11-Jan 12:10 |
| 20666 | Pekr | Help string to 'switch does not reveal much. And docs are imo even incorrect: "Switch also returns the value of the block it executes. The cases can be any datatype. If none of the other cases match, use the /DEFAULT refinement to specify a default case." | 11-Jan 12:09 |
| 20665 | Steeve | uhuh | 11-Jan 12:07 |
| 20664 | Pekr | The reason why /word has to be introduced is imo because exactly 'switch is not able to handle datytype directly in its body, and that is what I am pointing out ... | 11-Jan 12:07 |
| 20663 | Pekr | Steeve - I don't care. type?/word looks awfull ... | 11-Jan 12:06 |
| 20662 | Steeve | including R2-forward.r , 14 occurences in R2 8 occurences in R3 | 11-Jan 11:35 |
| 20661 | Steeve | the idiom [switch type? /word [...]] is used in such lot of places in mezz functions. You should be well aware of that now ;-) | 11-Jan 11:30 |
| 20660 | Rebolek | :) | 11-Jan 11:28 |
| 20659 | Steeve | Pekr, an old Reboler like you... | 11-Jan 11:26 |
| 20658 | Rebolek | file! in the switch body is not datatype! but word! Understanding this will help to better understand how REBOL works. | 11-Jan 11:24 |
| 20657 | Rebolek | By reading manual probably | 11-Jan 11:23 |
| 20656 | sqlab | no need for reducing type? first [#[datatype! file!]] | 11-Jan 11:23 |
| 20655 | Pekr | how is novice supposed to know, that actually submitting result of type? %user.r is not going to work with file! datatype in a switch body? | 11-Jan 11:22 |
| 20654 | WuJian | >> a: 1 == 1 >> switch a reduce [a ["ok"]] == "ok" | 11-Jan 11:19 |
| 20653 | Rebolek | "...switch should be supplied a reduced block" no, that's wrong. See: >> a: 1 == 1 >> switch 'a [a ["ok"]] == "ok" >> switch 'a reduce [a ["ok"]] == none | 11-Jan 11:18 |
| 20652 | Pekr | We are not talking about block here, but a function body. And if I write switch type? %user.r [file! [print "... a file"]] ... it is imo supposed to work ... | 11-Jan 11:16 |
| 20651 | Pekr | Rebolek - then switch should be supplied a reduced block :-) | 11-Jan 11:15 |
| 20650 | PeterWood | Graham: Binary is the default for read & write in R3. The documentation doesn't seem to have been fully updated for R3 yet, | 11-Jan 11:10 |
| 20649 | Rebolek | It may look confusing, but it makes perfect sense, it same as: >> a: 1 == 1 >> type? first [a] == word! >> type? first reduce [a] == integer! | 11-Jan 11:04 |
| 20648 | Rebolek | >> type? first reduce [word!] == datatype! | 11-Jan 11:02 |
| 20647 | Rebolek | because the block is not evaulated | 11-Jan 10:55 |
| 20646 | Pekr | Hmm, you are right: >> type? file! == datatype! >> type? first [file!] == word! | 11-Jan 10:55 |
| 20645 | Pekr | why is datatype a word? :-) | 11-Jan 10:54 |
| 20644 | Rebolek | So you need word! from type! or reduce the seitch block to get datatype! instead of word! . | 11-Jan 10:52 |
| 20643 | Rebolek | Pekr, return of type? is datatype!! but the datatype in the switch block is just word!, not datatype! . | 11-Jan 10:51 |
| 20642 | Steeve | type?/word is here for that | 11-Jan 10:50 |
| 20641 | Rebolek | Also this works: >> switch type? 1 reduce [integer! [print "ahoj"]] == ahoj | 11-Jan 10:50 |
| 20640 | Pekr | so return of 'type? is not a type? Well, we have not a datatype type? Yes, we have - datatype! .... but help reveals you can't do "to-datatype" ... | 11-Jan 10:49 |
| 20639 | Pekr | Graham, weird, but you can try: >> switch to-word type? %test.r [file! [print "... a file"]] ... a file | 11-Jan 10:48 |
| 20638 | Rebolek | Graham: >> switch type?/word 1 [integer! [print "ahoj"]] == ahoj | 11-Jan 10:46 |
| 20637 | Graham | Gab, you should pipe up with the source to pipe :) | 11-Jan 10:43 |
| 20636 | Graham | switch type? %test.r [ .... ] what do I need to write in the block to catch it ? | 11-Jan 10:40 |
| 20635 | Graham | how does switch on type? work? | 11-Jan 10:34 |
| 20634 | Graham | my lower level is working like this write port [ RETR "bigfile" %bigfile ] | 11-Jan 10:33 |
| 20633 | Gabriele | my implementation of PIPE is only a few lines. i think it should be native to R3. | 11-Jan 10:29 |
| 20632 | Gabriele | pipe ftp://somehost/somefile %/path/to/somefile | 11-Jan 10:29 |
| 20631 | Gabriele | Graham, I'd do what you want with: | 11-Jan 10:28 |
| 20630 | Graham | http://www.rebol.com/r3/docs/functions/write.html says there is a /binary refinement .. but this doesn't exist any more | 11-Jan 9:50 |
| 20629 | Pekr | Here's related ML discussion - http://www.rebol.org/ml-display-thread.r?m=rmlFDMJ | 11-Jan 9:39 |
| 20628 | Steeve | yup we should start with the html one in R3, it's a huge one currently | 11-Jan 9:38 |
| 20627 | Graham | I suspect that you have to write a few schemes to see what is needed and then write the scheme dialect | 11-Jan 9:37 |
| 20626 | Henrik | Ladislav has done one too. Time for a FSM battle? | 11-Jan 9:36 |
| 20625 | Pekr | One from gabriele - http://www.colellachiara.com/soft/Misc/qml/fsm.rlp | 11-Jan 9:33 |
| 20624 | Graham | Gregg | 11-Jan 9:33 |
| 20623 | Pekr | someone did FSM in the past. Gregg? Henrik? | 11-Jan 9:32 |
| 20622 | Steeve | Rebol is especially good with those things | 11-Jan 9:32 |
| 20621 | Graham | meta programming | 11-Jan 9:31 |
| 20620 | Steeve | yes a dialect to construct schemes | 11-Jan 9:31 |
| 20619 | Graham | Or do you mean use a dialect to define the scheme? | 11-Jan 9:30 |
| 20618 | Steeve | uniserve has some good ideas | 11-Jan 9:29 |
| 20617 | Steeve | ;-) | 11-Jan 9:29 |
| 20616 | Graham | Like uniserve? | 11-Jan 9:28 |
| 20615 | Steeve | shames=schemes | 11-Jan 9:28 |
| 20614 | Steeve | To my mind, we need a better framework to design shames using a FSM dialect | 11-Jan 9:28 |
| 20613 | Graham | We need a place to set a system timeout ... | 11-Jan 9:27 |
| 20612 | Graham | Steeve .. don't waste your time on a r2 chat .. there's no traffic on there. Spend your time on schemes :) | 11-Jan 9:24 |
| 20611 | Steeve | easy to talk hard to do | 11-Jan 9:24 |
| 20610 | Steeve | sorry again (it's true i said this) | 11-Jan 9:23 |
| 20609 | Graham | Well, I am using a write spec block ... | 11-Jan 9:22 |
| 20608 | Pekr | btw - some time ago someone stated here, that current https scheme is done "old school". Was that you? Isn't now the right time to define the better way (if any) to aproach schemes and networking? :-) | 11-Jan 9:22 |
| 20607 | Pekr | Steeve - it is good we have you here :-) | 11-Jan 9:21 |
| 20606 | Steeve | Well, we don't need of specific refinements, cause we can pass a block to read (which is converted to a port!). >> read [scheme: 'ftp host: ... path:... other_data: ....] The block format could be used to pass other parameters in a more handy way. >> read [ftp://ftp.rebol.com/matrix.avi file: %movies/matrix.avi] And the good news, is that it's absolulty possible to have something like that now. We just have to patch the function: system/intrinsic/make-port | 11-Jan 9:19 |
| 20605 | Graham | I think my schemes are making R3 unstable. Tried to post a message and got from chat rebol system error #1301: invalid datatype 99 ... should never happen ... | 11-Jan 8:51 |
| 20604 | Graham | Need some way to pass parameters to scheme actors. Andreas is using read/lines ! | 11-Jan 8:30 |
| 20603 | Pekr | hmm, but /as was proposed to specify just type of encoding IIRC, not some other functionality ... some of us wanted /as being more general, allowing you to specify a codec to decode. Codecs are so far inefficient (not streamed), because you have to read all data firts, then pass it to encode/decode. Carl never posted a resolution to read/write case .... | 11-Jan 8:27 |
| 20602 | Graham | read/as ftp://ftp.rebol.com/matrix.avi [ file: %movies/matrix.avi ] and to resume read/ask/seek ftp://ftp.rebol.com/matrix.avi [ file: %movies/matrix.avi ] current-file-size-of-matrix.avi | 11-Jan 8:17 |
| 20601 | Pekr | I am with ones proposing having read/write as simple as possible, adding just /as for codec support. Codec API should be defined, the same way as we have Device API, port API, etc. /string should be no excuse .... in the past (1.2 days), Holger posted to IOS: read http://something.com :my-callback | 11-Jan 8:16 |
| 20600 | Pekr | I don't know. Just read realated discussions - many opinions, what read/write should (not) do ... | 11-Jan 8:14 |
| 20599 | Graham | well, I guess we could specifiy it in the /as block | 11-Jan 8:13 |
| 20598 | Pekr | 16-Apr-2008: Prunning down read and write - http://www.rebol.net/r3blogs/0127.html 11-Nov-2009: Finalising read and write - http://www.rebol.net/r3blogs/0294.html | 11-Jan 8:08 |
| 20597 | Pekr | And maybe design of read/write was never actually finished ;-) | 11-Jan 8:07 |
| 20596 | Graham | Why not? Because refinements slow down 'read? | 11-Jan 8:05 |
| 20595 | Pekr | Graham: my reply from R3 Chat: I think that we will not get much refinements for read/write functions. The planned ones were /string (text) and /as (enconding). What you want is read working in a streamed way. We might get it in future, but I doubt we get what you propose. | 11-Jan 8:03 |
| 20594 | Graham | How about we have some more refinements to read ?? | 11-Jan 3:28 |
| 20593 | BrianH | Bolek, THROW and CATCH work in R3 but there is a strange interaction with TRY. | 7-Jan 22:28 |
| 20592 | Carl | Testing. | 7-Jan 22:23 |
| 20591 | Rebolek | throw/catch does not work in R3? | 1-Jan 13:35 |
| 20590 | BrianH | Rare for the kind of thing you tend to do though (emulators, iirc). | 31-Dec 23:20 |
| 20589 | BrianH | Not really, for code that plays to REBOL's strengths. It happens quite often. | 31-Dec 23:18 |
| 20588 | Steeve | rare | 31-Dec 23:17 |
| 20587 | BrianH | Oh, and that means that the mezzanine is faster than the native :) | 31-Dec 23:16 |
| 20586 | BrianH | An interesting example of that is AJOIN. The R3 version has less memory overhead, the R2 version in 2.7.7 is faster. | 31-Dec 23:15 |
| 20585 | Steeve | but there is several criteria to optimize something. - Best Speed - Shortest code - shortest memory overhead - best ratio of above criteria | 31-Dec 23:13 |
| 20584 | BrianH | That happened with some REBOL-vs-Java code the other day here. | 31-Dec 23:11 |
| 20583 | BrianH | For certain project domains, R3 interpreted code can be faster than compiled code, once it's been through the REBOL optimizer. | 31-Dec 23:10 |
| 20582 | Steeve | sure :) | 31-Dec 23:08 |
| 20581 | BrianH | It's the best optimizer known to man :) | 31-Dec 23:07 |
| 20580 | Steeve | -_-; | 31-Dec 23:06 |
| 20579 | BrianH | The "REBOL optimizer" is a running joke. The best way to optimize your REBOL code is to post it publicly in AltME or R3 chat and dare people to improve it. Then the community tries to one-up each other to improve it :) | 31-Dec 23:05 |
| 20578 | Steeve | Who's that optimizer ? | 31-Dec 23:03 |
| 20577 | BrianH | We should make a whole module of math functions, with test code. Let the REBOL optimizer at it and then see what we can include. | 31-Dec 23:02 |
| 20576 | Gregg | Maybe I'll remember if we write a test suite for it. | 31-Dec 22:55 |
| 20575 | Gregg | Yeah, I'm trying to remember (since I didn't comment it) why I coerced the result. Something in my brain says there was a good reason. | 31-Dec 22:54 |
| 20574 | BrianH | v1/1: v1/0 + :v2 | 31-Dec 22:53 |
| 20573 | Steeve | i was not seriously doing a proposal :-) | 31-Dec 22:53 |
| 20572 | BrianH | And faster. Reversing the order of arguments might not be a good idea though - some operators are more forgiving of their left value. | 31-Dec 22:52 |
| 20571 | Steeve | i should have used forall, less uggly :-) | 31-Dec 22:51 |
| 20570 | Gregg | It uses a lambda local. :-) | 31-Dec 22:49 |
| 20569 | Steeve | ... | 31-Dec 22:48 |
| 20568 | Steeve | yeah !!!! i do not use any locals | 31-Dec 22:47 |
| 20567 | Steeve | uggly one-liner version. sum: func[block [block!]][ foreach [v1: v2] next head reduce/into block copy [0 0][v1/1: :v2 + v1/0] ] -_-; | 31-Dec 22:45 |
| 20566 | Paul | ok. | 31-Dec 22:23 |
| 20565 | BrianH | In case reducing the block makes a function or some other active value - no double eval. It's a way to trip bad errors quicker. | 31-Dec 22:23 |
| 20564 | Paul | Your already reducing the block. | 31-Dec 22:20 |
| 20563 | Paul | why the :value? | 31-Dec 22:19 |
| 20562 | BrianH | That's the R3 way - throw a useful error so the programmer can fix their code, no DWIM :) | 31-Dec 22:14 |
| 20561 | BrianH | And it will just throw an error if the block contains anything not addable. | 31-Dec 22:13 |
| 20560 | Steeve | right | 31-Dec 22:12 |
| 20559 | BrianH | Not for a empty block. | 31-Dec 22:11 |
| 20558 | Steeve | foreach do that | 31-Dec 22:11 |
| 20557 | Steeve | no need to return the result at the end | 31-Dec 22:10 |
| 20556 | BrianH | Some error handing, some speedups, and vector support. | 31-Dec 22:10 |
| 20555 | BrianH | sum: func [block [block! vector!] /local result] [ result: 0 foreach value reduce block [result: result + :value] result ] | 31-Dec 22:09 |
| 20554 | Paul | Sounds like the function is moving along. Great thing is that if you build the one you have what you need for the product function as well. | 31-Dec 22:08 |
| 20553 | Gregg | Agreed. | 31-Dec 22:06 |
| 20552 | BrianH | Actually, documenting that this function doesn't do any error handling beyond the arguments of + would be good. | 31-Dec 22:05 |
| 20551 | Gregg | Agreed. The only issue is if you don't get a decimal value before an overflow occurs, but that's just something to doc. | 31-Dec 22:03 |
| 20550 | BrianH | Then any decimal or money in the list will promote. | 31-Dec 22:03 |
| 20549 | BrianH | We might not need to coerce to decimal. The first decimal in the list will make that coersion for us. And we don't want decimal results for a list of integers - it's a loss of precision. I suspect that initializing result with the integer 0 will be sufficient. | 31-Dec 22:02 |
| 20548 | Steeve | 0 seems better, it prevents throwing useless errors (my old claim) | 31-Dec 22:02 |
| 20547 | Gregg | Zero versus none is a good question Brian. I have SUM return zero, but my AVG func returns none. | 31-Dec 22:00 |
| 20546 | Gregg | Coercion to decimal would be to prevetn overflow. I prefer not to do that though. | 31-Dec 21:59 |
| 20545 | Steeve | yep, but we are always waiting | 31-Dec 21:56 |
| 20544 | BrianH | Vector math has already been suggested. | 31-Dec 21:55 |
| 20543 | Steeve | well, if only the default math operators could accept series of scalars by default, it would be incredibly simple and powerful. It should not be so hard to have that behaviour nativly... A + [1 2 3 4] == A + 1 + 2 + 3 + 4 | 31-Dec 21:54 |
| 20542 | BrianH | Should sum [] return 0 or none? | 31-Dec 21:53 |
| 20541 | Paul | Why the coersion to decimal? Just curious. | 31-Dec 21:50 |
| 20540 | Paul | I just added the wish request. | 31-Dec 21:47 |
| 20539 | Gregg | I'm all for it. I've suggested them in the past, but didn't get much traction. Here's a non-recursive starting point. ; Should our seed value be 0.0 to coerce to decimal? If they ; include a decimal value before any overflow, it will be OK. ; Changed to match the first type in the block. sum: func [block [any-block!] /local result] [ result: any [ attempt [make pick block 1 0] attempt [0 * pick block 1] 0 ] foreach value reduce block [result: result + value] result ] | 31-Dec 21:44 |
| 20538 | Paul | will do when I get the chance. | 31-Dec 21:12 |
| 20537 | BrianH | Suggest them in CureCode as wishes. Or write them up as mezz or extension functions - those are easy to adapt. | 31-Dec 21:09 |
| 20536 | Paul | >> sum [1 2 3] ==6 | 31-Dec 21:07 |
| 20535 | Paul | what about a sum or product functions for R3? | 31-Dec 21:07 |
| 20534 | BrianH | Especially when the features can be added later. The rapid release model means that "later" releases are still coming soon :) | 30-Dec 19:39 |
| 20533 | sqlab | I think you should stick to announced release dates. Better axe some features than not to deliver | 30-Dec 11:36 |
| 20532 | BrianH | And in the meanwhile, R3 is usable for some purposes now. More so with some bug fixes. It will be time to go beta soon. | 30-Dec 10:10 |
| 20531 | BrianH | Task-safety will require a full code review, natives included. Probably some adjustments to the system model and module code too. | 30-Dec 10:09 |
| 20530 | BrianH | Nonetheless, extensions and host code in a more usable state is likely. Concurrency less so for the 3.0 release - concurrency is a big issue that needs more review, particularly once the subtleties of the model are well known enough to make the mezzanines task-safe. | 30-Dec 10:06 |
| 20529 | BrianH | Rapid release model, remember. There's no such thing as a final feature set. Beta means that what is there is expected to work. | 30-Dec 10:04 |
| 20528 | Pekr | I would like to see Extensions and Host code finished to final state (it means support for devices, vectors, callbacks, etc.), and concurrency added too, or it imo has no sense to call it a beta ... | 30-Dec 9:54 |
| 20527 | BrianH | nlikely -> unlikely | 30-Dec 9:49 |