| # | User | Message | Date |
| 2897 | Oldes | Isn't it usually integer? It's must be defined somewhere btw. | Tue 23:56 |
| 2896 | Pekr | Cyphre: thanks, will try that ... | Tue 18:16 |
| 2895 | Cyphre | Pekr, bool in C is usually of char type so you should try to set the returned value in your routine! spec to char. | Tue 16:52 |
| 2894 | Pekr | I can't influence it, it is just result from the mapped function C level code bool (dunno how it is defined) to R2's integer! value. Was just curious .... | Tue 14:26 |
| 2893 | Geomol | w> to binary! 30605312
== #{0000000001D30000} Maybe you read too many bits? | Tue 14:19 |
| 2892 | Pekr | One question to library wrapping. I have a function, which should return a bool from C level, according to if the communication card is open, or not. When I am able to open the card, it returns 1 (mapped to R2 integer!), if not, it returns 30605312 - does that integer make any sence? I mean, does it e.g. translate to some C level slot, overflow, or -1 value? Just curious ... | Tue 14:10 |
| 2891 | Geomol | Ah, it is. I just realized, when I wrote it. :) | Tue 9:22 |
| 2890 | Geomol | Copying a cyclic block: >> blk: [a b c] == [a b c] >> insert/only blk blk == [a b c] >> blk == [[...] a b c] >> copy blk == [[[...] a b c] a b c] That's not correct, right? | Tue 9:21 |
| 2889 | Ladislav | Well, sure, the speed may not be the most important property. | Mon 16:14 |
| 2888 | Gregg | Lad +1 The REOL Syntax project is very important in this regard, and documenting the differences between the clones. Being the fastest VM my not be John's goal, if it means other tradeoffs. | Mon 16:01 |
| 2887 | Ladislav | "That's the problem with closed source languages" - there is nothing like "closed source language". Only an interpreter/compiler may be closed source. | Mon 13:25 |
| 2886 | Steeve | I mean, even Carl failed in that matter. Everyone do shitty design choices occasionally. It's why it's better to have friendly eyes behind our shoulder. | Mon 11:34 |
| 2885 | Steeve | Geomol, I already know that you made some technical choices in World that I would not have done because I think (maybe I'm wrong) I know better ways to do faster VM. So, to my mind,you already failed in the task to deliver a promising clone. Just to say that your 'needs' , expectations and technical skills are probably not the best in each room. ;-) | Mon 11:22 |
| 2884 | Geomol | But that doesn't exclude, that if I use some time and think about some problem, I can figure out, if it's doable in some language the 'right' way. | Mon 11:11 |
| 2883 | Geomol | sure | Mon 11:10 |
| 2882 | Steeve | We all do mistakes even after years and years of practices | Mon 11:10 |
| 2881 | Steeve | We all do mistakes even after years and years of practices | Mon 11:10 |
| 2880 | Geomol | A good language is also easy to expand and integrate with other technologies. For some projects, it may be a good idea to have the language as a dynamic linked library. | Mon 11:10 |
| 2879 | Geomol | :) nah | Mon 11:09 |
| 2878 | Steeve | Lol, Are you 20 or what ? | Mon 11:09 |
| 2877 | Geomol | Ah, I have enough programming experience to figure out, if something is doable the 'right' way or not. | Mon 11:08 |
| 2876 | Steeve | Others have needs you don't care in the end. | Mon 11:08 |
| 2875 | Steeve | The problem is that what you think is the correct way to do things may be not | Mon 11:07 |
| 2874 | Geomol | I don't care, if my C compiler is closed source or not, because it just works. I also shouldn't care, if my COBOL compiler and interpreter is closed source or not, but I actually do, because the company behind can't figure out to make graphical tables (called GRIDs) the correct way, so my COBOL programs doesn't work as intended, and I have to create work-arounds. Years ago, I didn't care, if REBOL was closed source or open, but later I did, because I couldn't finish projects, I made with it. Any future language, I would use, I don't care if it's closed or open, if it delivers, what it promices. If it doesn't, it's another case. | Mon 11:04 |
| 2873 | Pekr | Geomol's right. R2 can be extended via DLLs, and R3 via extensions. But that might not solve all usage cases or needed fixes in Core ... | Mon 10:52 |
| 2872 | Geomol | Or ... if the language makes you do anything, like e.g. C, and what it does, it does well, then it doesn't matter, if it's closed source or not. | Mon 10:50 |
| 2871 | Geomol | Exactly! :) | Mon 10:48 |
| 2870 | GrahamC | lol | Mon 9:33 |
| 2869 | Rebolek | That's the problem with closed source languages, if author doesn't add something, you're out of luck. | Mon 9:29 |
| 2868 | Geomol | I too wish, more work was put into R2, instead of doing R3. That's one reason, why I develop World. | Sun 11:17 |
| 2867 | Geomol | Right. | Sun 11:16 |
| 2866 | Oldes | of course... if you add one more condition to detect if the key exists... it does not change anything on the fact, that R2 is missing one of the basic functionalities natively. | Sun 11:15 |
| 2865 | Geomol | Or wrap it in a context: map: context [ keys: make hash! ["a" "b"] values: ["b" "c"] pick: func [value] [ system/words/pick values index? find keys value ] ] >> map/pick "a" == "b" >> map/pick "b" == "c" | Sun 11:08 |
| 2864 | Geomol | Maybe do somehing like: >> keys: make hash! ["a" "b"] == make hash! ["a" "b"] >> values: ["b" "c"] == ["b" "c"] >> pick values index? find keys "a" == "b" >> pick values index? find keys "b" == "c" The pick values index? find keys could be put in a nice function to call. | Sun 11:04 |
| 2863 | Endo | Oldes: I was just about to write this, I asked is this a bug a few months ago, but no, it returns a block when you select with /skip because you can select more-than-one value if your skip size is > 2 , otherwise you cannot get the further values. You select block of values when use /skip. | Sun 10:46 |
| 2862 | Oldes | Hm.. the reason for the additional block with the /skip is thi sone: >> b: ["a" "b" "c" "d" "b" "c" "d" "e"] select/skip b "b" 4 == ["c" "d" "e"] | Sun 10:16 |
| 2861 | Ladislav | ...also, I am not sure, but maybe BrianH also offers his own version | Sun 10:15 |
| 2860 | Ladislav | I gave up even longer time ago offering my code :-p | Sun 10:14 |
| 2859 | Ladislav | That is not complete in that it does not handle other operations than GET-ATTRIBUTE | Sun 10:13 |
| 2858 | Oldes | And I will not ask.. I was asking so many times without any response that I gave up long time ago. | Sun 10:13 |
| 2857 | Oldes | I have the code:
get-attribute: func[name /local tmp][all [tmp: select/skip attributes name 2 first tmp]] but it's so UGLY. | Sun 10:12 |
| 2856 | Oldes | The question is when his weekend starts.. if his hour has so many minutes... but it would be nice to have his weekend using same hour type. | Sun 10:12 |
| 2855 | Ladislav | Oldes, why don't you: - ask for the R2 Map! code or - write your own instead of writing that "if I could"? | Sun 10:12 |
| 2854 | GrahamC | Didn't he "say" that he was going to spend some weekend time on it? | Sun 10:10 |
| 2853 | Oldes | If I could move time back a few years and I could vote, I would like Carl to enhance R2 a little bit instead of starting R3 which he probably never finish. | Sun 10:10 |
| 2852 | Ladislav | "To have separate hashes for key and values would be even more complicated" - that is wrong, there is no need to have two hashes, moreover, it is not complicated, I wrote the corresponding software, and it is easy | Sun 10:09 |
| 2851 | Oldes | In my case I will have just a few key-value pairs.. so the speed is not a problem, more important is to be safe that the key will not be mixed with values. | Sun 10:08 |
| 2850 | Oldes | I know the theory:/ To have separate hashes for key and values would be even more complicated. I would be fine if the select/skip would not return a block which is simply stupid... or correct me if there is any reason for that. It's sad we cannot have map! in R2. | Sun 10:07 |
| 2849 | Ladislav | (hope it explains it a bit) | Sun 9:50 |
| 2848 | Ladislav | MAP is an associative (Key <-> Value) data "storage". In R2 a correspoding way would be to use the hash! datatype, however, if you want to discern keys from values you need to use a separate Keys hash! and a separate Values block, otherwise you end up having Keys and Values intermixed. Your way of using the /skip refinement and a block is slower, however it searches only in Keys as well due to the /skip 2 use. When not used, it would search in Values. | Sun 9:49 |
| 2847 | Oldes | It's really sad to know, that we cannot expect any improvements in a future:/ | Sun 9:47 |
| 2846 | Oldes | I really would like to know, why the hell is the result with /skip refinement in block:/ | Sun 9:45 |
| 2845 | Oldes | in R3:
>> b: make map! ["a" "b" "b" "c"]
== make map! [
"a" "b"
"b" "c"
] >> select b "b" == "c" in R2 I know only: >> all [tmp: select/skip b "b" 2 first tmp] == "c" | Sun 9:40 |
| 2844 | Oldes | What is the best way how to simulate R3's map! in R2? It would be enough to have safe key-value pairs? | Sun 9:37 |
| 2843 | Geomol | Technical speaking, it's an expanded coercion for the equal operator, =, (and so also for the equal? function). | Fri 19:09 |
| 2842 | Geomol | No, let me clarify. I want integer! to represent a datatype, like 1 represents an integer. So datatype? integer! should return true, and word? integer! should return false, just like decimal? 1 returns false. I simple suggest equal? to return true, when comparing a datatype with a word of the same spelling. Like this is true: >> equal? 1 1.0 == true | Fri 19:03 |
| 2841 | Gregg | There is a big difference between having datatypes be word values, versus having them fall under the any-word pseudotype. The latter seems OK, but not the former. If I understand you, it would cause things like [datatype? integer!] to fail, because it would return word!. That is, we lose them as an identifiable datatype. I use them for reflective tools and dialects. While the change wouldn't make that impossible, I like them being first class citizens as they are today. | Fri 17:53 |
| 2840 | Andreas | In any case, I wouldn't conflate that question with the question of #[true] = 'true. | Fri 15:53 |
| 2839 | Geomol | w> /refinement = 'refinement
== true The question is, if the following would lead to a disaster? w> integer! = 'integer! == true | Fri 14:30 |
| 2838 | Geomol | Integers are not decimals, but they're both numbers, and we can check like: >> 1 = 1.0 == true Refinement are not words, but they're both any-words. Why not let datatypes (and none and logic) be any-words just the same? If the benefit from doing so is big, then it could be a good idea. | Fri 14:23 |
| 2837 | Andreas | Note that we also have a literal syntax for none! and logic! values now, which makes all your finds succeed even without reducing: >> find [#[true]] true == [true] Etc. | Fri 13:46 |
| 2836 | Andreas | none! and logic! are simply not word types, so it makes no sense to have them in the any-word! typeset. none/true/false being words conveniently pre-bound to values of the corresponding datatypes does not change that. | Fri 13:45 |
| 2835 | Geomol | It's funny, that the following succeed, but for another reason: >> find [word!] word! == [word!] | Fri 11:39 |
| 2834 | Geomol | refinement! is member of the any-word! typeset together with word!, set-word!, get-word! and lit-word!. My thoughts above lead to asking if also none! and logic! should be part of any-word! with datatype! too? Examples from R2: >> /ref = 'ref == true >> find [/ref]Ê'ref == none ; this is strange to me Maybe all the next should succeed? >> find [true] true == none >> find [none] none == none >> find [integer!] integer! == none | Fri 11:35 |
| 2833 | Ladislav | FYI - datatypes were never words, but they were examples of specific datatypes in R1 | Fri 11:28 |
| 2832 | Geomol | Maybe the question should be put the other way around: Are there cases (in real scripts), where it would be a problem, if datatypes equals words? | Fri 11:15 |
| 2831 | Geomol | I know, I today can write things like either find [#[datatype! block!] #[datatype! paren!]] type? value [ ... but I don't do that, because it has too much syntax for my taste, and therefore isn't very readable. | Fri 11:12 |
| 2830 | Geomol | If datatypes equals words, like word! = 'word!, then maybe the refinement in type?/word isn't needed? But what are the consequences? The next two examples would return the same: >> find [integer! 42] integer! == [42] >> find [integer! 42] 'integer! == [integer! 42] I came to think of this, because I find myself writing things like the following all the time now: either find [block! paren!] type?/word value [ ... and switch type?/word value [ ... If datatypes equals words, only type? without the refinement would be needed. | Fri 11:04 |
| 2829 | PeterWood | /library is not a free part of Core only View. | 11-Feb 9:46 |
| 2828 | Pekr | There is several various paths in R2 structure, dunno if it is just weird R2 implementation, or OS level natural functionality ... | 11-Feb 9:34 |
| 2827 | Pekr | My observation is, that if there are one or more dependant DLLs, REBOL will load first one, but then the path is somehow not taking into account a present directory. Here's few pointns: - you can't do: do %my-dir/my-dll-script.r - nor you can do so after: change-dir But it works, when you launch REBOL from the directory where those DLLs are present. | 11-Feb 9:33 |
| 2826 | Pekr | I'll continue here for now, as /library is now a free part of Core, and DLL.SO is not web-public. | 11-Feb 9:31 |
| 2825 | Maxim | it also looks in the current-dir... but that path will depend of how you launched rebol. use WHAT-DIR just before you try to load your dll to know where the current-dir is at that time and put your dll there. you can also add a path in the user or system path environment and place the dll there. | 10-Feb 16:49 |
| 2824 | Endo | Pekr: Registration (regsvr) is required only if they are ActiveX DLLs, but I think they are not because you cannot use ActiveX DLLs in REBOL. Normally they should be somewhere in your PATH. Try to see what's happening with FileMon tool from Systeminternals.com. | 10-Feb 16:07 |
| 2823 | Oldes | I don't know how it's on Vista, but on W7 or XP you can place it anywhere... I today updated my old zlib script to do late initialisation, you can find it here: https://github.com/Oldes/rs/tree/88291b8c720e9026978a080ca40100c3f2fb780f/projects-dll/zlib/latest | 10-Feb 15:33 |
| 2822 | Pekr | or should I register them somehow using regsvr or something like that? | 10-Feb 15:30 |
| 2821 | Pekr | where should I put DLLs, in order for REBOL to find them? I mean - I have one DLL, which is dependant on some other. Even if I put that DLL into the same directory, it complaints it can't find it. Win Vista here ... | 10-Feb 15:30 |
| 2820 | Steeve | Anyway O(n*n) is by far too dramatic ;-) | 10-Feb 0:14 |
| 2819 | Steeve | Max, although I think you're comparing O(1) vs O(n) parsing algorithms (random access vs linear)
(The indexing part is probably meant to be O(n.log n) because it involves sorting data, but should be taken apart from the parsing cost) just wandering around, uhuh | 10-Feb 0:11 |
| 2818 | Maxim | I always love when I realize that I write things like this in Rebol: -*&*&*&*-: "a pretty impossible to guess variable name :-)" | 9-Feb 23:52 |
| 2817 | Maxim | "O*O*n" == a typo :-) I guess I really meant something like O(n*n) Its the kind of dramatic linear vs logarithmic scaling difference when we unfold our datasets into parse. but its not exactly that kind of scaling, since the average topology of the sort tree will have a lot of impact on the end-result. for example in my system, when I try to index more than the first 5 characters, the speed gain is so insignificant that the ratio is quickly skewed, when compared to the difference which the first 3 letters give. Its 100% related to the actual dataset I use. in some, going past 2 is already almost useless, in others I will have to go beyond 5 for sure. in some other datasets we unfold them using hand-picked algorythms per branch of data, and others its a pure, brute force huge RAM gobler. | 9-Feb 22:58 |
| 2816 | Ladislav | Use case for default: to-string [1 "." 2] ; == "1.2" | 9-Feb 22:43 |
| 2815 | Ladislav | What is "O*O*n"? | 9-Feb 22:32 |
| 2814 | Maxim | I'm not complaining, I just find absolutely no use-case for the default :-D my question was can anyone give me a reason for the current use of to-string? can you? ;-P | 9-Feb 22:17 |
| 2813 | Steeve | You can use FORM as well. And having alternatives should not be something to complain about. :) | 9-Feb 20:40 |
| 2812 | Sunanda | Something inconsistent in the way paths are handled: to-string load "path/item" == "pathitem" to-string to-path "path/item" "path/item" | 9-Feb 20:23 |
| 2811 | Oldes | funny.. I was thinking about it today as well.. but I don't know | 9-Feb 19:41 |
| 2810 | Maxim | can anyone explain a single use for this R2 path conversion? >> to-string first [path/item] == "pathitem" I know I can use mold... it's just that I wonder why to-string doesn't use the molded string equivalent as well? | 9-Feb 19:24 |
| 2809 | Maxim | (btw that 1.6GB limit used to be a real problem when I was doing 3D stuff... 3D animation apps are memory hogs, and in some cases, we could only work 15 minutes before high-end apps would crash. which is a problem when a 3D scene takes 30 minutes to save to disk over the network ;-) | 9-Feb 18:38 |
| 2808 | ddharing | I see. What about Linux? | 9-Feb 18:36 |
| 2807 | Maxim | it may be higher on linux, I've never tested it. | 9-Feb 18:36 |
| 2806 | Maxim | its the MS windows limit. it can only address 1.6GB of memory in 32-bit mode. | 9-Feb 18:35 |
| 2805 | Maxim | yeah... I've got a server that has 64GB of RAM I want to use it !!! :-) | 9-Feb 18:35 |
| 2804 | ddharing | I'm confused. Why is REBOL limited to 1.6GB? I've seen that myself too, but that is nowhere near the 4GB limit. | 9-Feb 18:35 |
| 2803 | ddharing | Memory is cheap. It's the 32-bit limit that is the real problem -- as you stated. | 9-Feb 18:34 |
| 2802 | Maxim | Our datasets are huge and we optimise for performance by unfolding and indexing a lot of stuff into rules... for example instead of parsing by a list of words, I parse by a hierarchical tree of characters. its much faster since the speed is linear to the length of the word instead of to the number of items in the table. i.e. the typical O*n vs. O*O*n type of scenario . just switching to parse already was 10 times faster than using hash! tables and using find on them.... In the end, we had a 100 time speed improvement from before parse to compiled parse datasets. this means going from 30 minutes to less than 20 seconds....but this comes at a huge cost in RAM... a 400MB Overhead to be precise. | 9-Feb 17:00 |
| 2801 | Maxim | The problem with R3 right now is that it isn't yet compiled in 64-bits we still have the 1.6GB RAM limit for a process which is the biggest issue right now. I have blown that limit a few times already, so it makes things a bit more complex and it doesn't allow me to fully optimize speed by using more pre-generated tables and unfolded state rules. | 9-Feb 16:59 |
| 2800 | james_nak | Thanks Maxim. I appreciate the info. | 9-Feb 16:52 |
| 2799 | Maxim | R2. since we compile just about all the rules from other datasets and simplified user-data, the R3 advantage is much less significant (because we can simulate all the R3 improvements by using R2 idoms, though its sometimes tricky). Using R3, it probably would be a few percent faster since some of the rules we have would be simpler and those tricks would be managed natively by parse rather than by *more* parse rules. | 9-Feb 16:41 |
| 2798 | Pekr | Max - are you using R2 parse, or R3 enhanced one? | 9-Feb 16:37 |
| 2797 | Maxim | I learnt parse using the 2.3 rebol core guide... I thought it did a pretty good job of launching one in the good direction. parse HAS evolved since then, but for the basic semantics and principles of parsing I think its pretty good. you can also look at this tutorial by Nick Antonaccio: http://musiclessonz.com/rebol_tutorial.html#section-9.3 IIRC nick has a good sense of tutoring, so it may be a good first step... he also gives links to other parse resources at the end of that part of his (short) tutorial | 9-Feb 16:32 |
| 2796 | james_nak | Guys, with all this said (and I agree), perhaps this is the one things that needs to be the focal point for Rebol and eventually the #Not Rebol languages. I know there are some tutorials out there but do any of them do justice to parse? I keep going back to the Codeconscious one: http://www.codeconscious.com/rebol/parse-tutorial.html and the ones at reboltutorial, but there doesn't seem to be a lot considering how much one can do with it. | 9-Feb 16:24 |
| 2795 | ddharing | Well said, Oldes. | 9-Feb 15:28 |
| 2794 | Pekr | REBOL parse is a gem, a treasure to follow. Me, the coding lamer, did few things using it. Guys coding C++ first came meh, well, interpreter. Then - how is it possible it is faster than C++ app? Later on, they came with new requests asking - well, you know, you have that parser, we need to do following stuff ... | 9-Feb 6:19 |
| 2793 | Oldes | Parse is REBOL's heart... I cannot imagine living without it. | 8-Feb 20:17 |
| 2792 | Maxim | learning parse requires baby steps and at some point, the decision to solve a real problem with it and force yourself to learn it. I didn't use parse for almost a decade until I started using it more and more to a point that currently I do more parse than any other coding in REBOL (but that's just because its idealy suited for this). some little tricks accumulate with experience and eventually, we discover pretty wacky things, which allow us to use parse almost like a VM. | 8-Feb 18:58 |
| 2791 | james_nak | That's incredible Maxim. Good work. With what you do with parse, is the knowledge available online in tthe form of the present parse documentation, or did you have to discover new techniques? I have to admit I just barely use it when I need to. Anyway, thanks for sharing your experience. I | 8-Feb 18:34 |
| 2790 | Maxim | hehe, I wasn't sure ;-) | 8-Feb 6:32 |
| 2789 | GrahamC | Not sarcasm .. just humor :) | 8-Feb 6:32 |
| 2788 | Maxim | hum... either that was sarcasm or you mean, what is the company I now work for? | 8-Feb 5:43 |
| 2787 | GrahamC | Who is this guy? | 8-Feb 5:23 |
| 2786 | Maxim | in my last test I was doing natural language extraction of concepts at a rate of 25000 words a second within multi-megabyte text files. :-) | 8-Feb 4:53 |
| 2785 | Maxim | I think people don't realize just how much power lies in parse. Even I'm impressed with it right now. I've been doing tests with really crazy stuff like two-cursor parse rules and run-time auto-recompilation of 400MB parse rules. I've been doing things like parsing 100MB word documents and pushing the interpreter to the limit ... reaching the 32-bit 1.6 GB RAM limit, 6 hour loop tests, etc. :-) | 8-Feb 4:47 |
| 2784 | Maxim | (eek that was redundant, sorry ;-) | 8-Feb 4:39 |
| 2783 | Maxim | I've been working a lot lately, and haven't had a lot of spare time. I'm actually working with REBOL full time at a company which is using it to get a significant competitive advantage over the competition. | 8-Feb 4:38 |
| 2782 | james_nak | Thanks. I wish there was a way to compare words like this so one could find out what the difference was. I suppose that is part of the bindology world. Glad to hear you are working with Rebol. It could be me but I haven't seen you around lately. Probably me because I haven't been around much here myself. | 8-Feb 2:45 |
| 2781 | Maxim | since I've been doing parse compilers for the last 2 months, I can say this have happened even more often lately ;-) you might also look up the 'COMPOSE word, it's very handy for resolving these kinds of issues (considering it's this kid of issue to begin with ;-) | 8-Feb 2:37 |
| 2780 | james_nak | Thanks Maxim. | 8-Feb 2:35 |
| 2779 | Maxim | often, I'd build a block to be used and forget to reduce the block before appending it to the spec. so what happens is that you receive an unbound word, instead of the data you assumed it should be refering to. | 8-Feb 2:16 |
| 2778 | Maxim | James, I think you are mixing up the word which refers to an object with an object value. this is confusing in Rebol because words are not variables. it's happened to me a few times (especially in VID) that I mix this up in action blocks and VID dialect builders. | 8-Feb 2:15 |
| 2777 | james_nak | Gregg, thanks, it could be the func that's getting the arg, the "dosomething" in my example. I hadn't look at that though I was wondering still what the difference was with the two objects. Unfortunately it always seemed right even with the types defined because they were both objects. At least that's what type? outputted. Maybe it has something to do with the context they were bound to. Anyway, that's for another day. Thank you as always. | 3-Feb 23:28 |
| 2776 | Gregg | If the func doesn't take a lit-word/get-word argument, it should evaluate and pass as an object. Now, if you have a block of words that refer to list faces, and you pass that word, that's what you get. If your func has types defined for the args, that can help catch issues like this. | 3-Feb 23:15 |
| 2775 | james_nak | Thanks Graham and Gregg. The object that I was passing was a face and I tried different ways to get it to work and that was the only way it would work. I guess the question is how does one know when he is passing some value if the receiving function sees it as the writer is intending it to be seen. Anyway for now I am satisfied and have moved on to other issues. I appreciate your input though. | 3-Feb 22:37 |
| 2774 | Gregg | In your example, you didn't spec the /do-this refinement on the call. Probably just a glitch in posting here though. | 3-Feb 22:08 |
| 2773 | GrahamC | You can pass functions as parameters, and then omit the 'do | 3-Feb 20:56 |
| 2772 | james_nak | OK, figured it out. I had to pass the object as a 'word then "do" it in the function to get it to work. | 3-Feb 20:11 |
| 2771 | james_nak | Nope, that wasn't it and I'm back to wondering what's the difference between the object and the passed object. | 3-Feb 19:48 |
| 2770 | james_nak | Hold on. I think I might be testing the wrong thing. | 3-Feb 19:15 |
| 2769 | james_nak | =doesn't work. | 3-Feb 19:08 |
| 2768 | james_nak | I've got a function that doesn't and I know one of you can explain why.
foo: func [ /dothis anobject ] [
if dothis [
dosomething anobject
]
] foo myobject So the dosomething function does not work with the "anobject". However, If I hardcode the "myobject" into foo like: foo: func [ /dothis ] [ if dothis [ dosomething myobject ] ] It works. So my questions are: Is it because "anobject" is a pointer? And what do I do on the calling/receiving sides to fix that? Thanks in advance. | 3-Feb 19:07 |
| 2767 | Gregg | Only Carl can say if it's by design or not. | 3-Feb 18:17 |
| 2766 | Endo | Thank you guys. I know the behaviour of charset in FIND. But I expect to skip the char that found, if I use /TAIL refinement as in using string. Same for /LAST as Gregg said. It ignored for charsets. And also; >> find/reverse "endo" charset "d" == none a bit confusing.. | 3-Feb 16:09 |
| 2765 | sqlab | I know that charsets find the first occurance of any of the chars, but maybe Endo knows that too. So I should probably not remind. | 3-Feb 14:40 |
| 2764 | Maxim | sorry for the color... It got stuck, I didn't realize I was in yellow ;-) | 3-Feb 14:20 |
| 2763 | Maxim | sqlab, a charset is not a string its a bitset, so it will search for ALL the characters in the charset at each byte... also note that when using find, charsets are case sensitive (and very fast). the bug with /tail is pretty surprising, I never noticed it. | 3-Feb 14:19 |
| 2762 | Geomol | Combination of find/tail and charset looks like a bug to me. | 3-Feb 10:38 |
| 2761 | sqlab | be aware, that find with charsets behaves differently in more ways >> find "abc" charset "db" == "bc" | 3-Feb 4:23 |
| 2760 | Gregg | I think /last and /tail only apply to string values. Perhaps a feature that hasn't come to pass yet? :-) | 2-Feb 23:50 |
| 2759 | Endo | When I use FIND with CHARSETs it ignores the /TAIL refinement. Is this a bug? ;with charset >> find/tail "abc" charset "b" == "bc" >> find "abc" charset "b" == "bc" ;with string >> find "abc" "b" == "bc" >> find/tail "abc" "b" == "c" | 2-Feb 22:35 |
| 2758 | GrahamC | Ok, I'll suggest this .. | 2-Feb 17:19 |
| 2757 | Pekr | note: the reason I used to-rebol-path was, that directory names contained spaces .... | 2-Feb 16:10 |
| 2756 | Pekr | I just tried: do to-rebol-file "L:\some\path\here\test.r" and everything went OK, Win Vista here. Console is being launched form the shortcut on start bar, pointing to renamed to rebol.exe | 2-Feb 16:09 |
| 2755 | Endo | Also try to use the full path. Once I have faced a problem CALL with REBOL style file! value. It worked with a windows-style path. And also have problem with /shell worked on my XP but did not on my customers W7. | 2-Feb 15:55 |
| 2754 | SWhite | GrahamC, thank you for passing this around. I did get part way to a solution, as noted on your site. Strange as it may seem, I am able to get to the network drives if I run a copy of REBOL that I download and leave with the name it came with, namely rebol-view-278-3-1. The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, but I had renamed it to rebview to make a desktop shortcut work. I had the name "rebview" in the shortcut so that I would not have to change the shortcut if I ever got an upgraded version of REBOL with a different name, like maybe rebol-view-279. So my first problem with WIndows 7, REBOL, and network drives seems fixed. I still am not to a full solution to my Windows 7 issues. I have some REBOL scripts that use the "call" command to run powershell. Powershell then runs a powershell script to extract stuff from an EXCEL spreadsheet, which then is manipulated by the REBOL script. Actually it's a bit messier. I run a REBOL program launcher on the C drive which runs a REBOL script on a network drive. The script on the network drive calls powershell with parameters to make powershell run a powershell script. The powershell script extracts EXCEL data, and the calling REBOL script then makes a report of the extracted data. When I try to do this, the result from powershell is that I am not allowed to run scripts on that computer. I am aware of this feature of powershell, and I have done what has worked for Windows XP (set-executionpolicy remotesigned). I can run powershell directly, and execute scripts located on a network drive. When a REBOL script that worked on XP calls powershell on WIndows 7, it won't go. I am not expecting any help with this last issue at this time because the "call" does work in some cases (call/shell "notepad") (call/console/show "powershell"), so I still have several things to try, and if none work I am plotting a work-around. | 2-Feb 15:47 |
| 2753 | james_nak | Graham, gotta love that Win 7. I was about to move all my belongings to a W7 machine and retire my XP but not now. | 1-Feb 22:06 |
| 2752 | Pekr | Interesting. I remember some talk about it in the past, but I thought it was fixed, or it was a different issue. I will try tomorrow at my work, our share is called "L:" too :-) | 1-Feb 19:29 |
| 2751 | GrahamC | http://www.synapse-ehr.com/community/threads/rebol-on-windows-7-and-a-network.1424/#post-10560 Anyone? | 1-Feb 19:11 |
| 2750 | Sunanda | Just remember that a function does not really have a name. Just the name, if any, by which you called it: b-function: c-function: :a-function ;; one function, many names do reduce [:a-function] ;; one function, no name | 31-Jan 19:14 |
| 2749 | Endo | cool :) | 31-Jan 18:27 |
| 2748 | Oldes | ah.. good one:) | 31-Jan 18:10 |
| 2747 | Sunanda | In R2, use the catch-an-error trick a-function: func [][print ["i am named " get in disarm try [0 / 0] 'where]] a-function i am named a-function | 31-Jan 18:05 |
| 2746 | Oldes | Hm... that would be enough, but I'm in R2 now. | 31-Jan 17:44 |
| 2745 | Andreas | However, In R3, you can use the stack inspection native STACK for an approximation: >> foo: func [] [print stack/word 1] >> foo foo >> bar: :foo >> bar bar | 31-Jan 17:43 |
| 2744 | Oldes | So far I'm using this: myfunc: func[ "Defines a user function with given spec and body." [catch] spec [block!] {Help string (opt) followed by arg words (and opt type and string)} body [block!] "The body block of the function" /local desc ][ if parse spec [set desc string! to end][ insert body reduce ['log desc] ] throw-on-error [make function! spec body] ] | 31-Jan 17:43 |
| 2743 | Andreas | In general, no, as functions need not be bound to a word. | 31-Jan 17:41 |
| 2742 | Oldes | Is it possible to get function name from inside the function body while it's procesed? | 31-Jan 17:38 |
| 2741 | Geomol | So there is a difference, if no type is specified and if any-type! is specified. Like in: >> f: func [v][] >> f ** Script Error: f is missing its v argument >> f: func [v [any-type!]][] >> f HELP does display it differently. In the first case, it's: ARGUMENTS: v -- (Type: any) and the second: ARGUMENTS: v -- (Type: any-type) Subtle differences. And you're correct, Ladislav. Insert and append sould take the same kind of argument. | 18-Jan 10:02 |
| 2740 | Gregg | Wow. I think so. Not that I remember needing to append UNSET values but, if that's the underlying behavior, it seems APPEND should be consistent. | 17-Jan 18:30 |
| 2739 | Ladislav | Hi all, I thought that this one has already been solved... Apparently not: The VALUE argument of the APPEND function is not defined as [any-type!] (in contrast to INSERT). I think that this should be corrected in R2, shouldn't it? | 17-Jan 16:48 |
| 2738 | Mikesz | Thankyou! | 16-Jan 19:07 |
| 2737 | Gregg | In R2 you can't add words to an existing object, you have to make a new object (as you are above) and change the reference in the block to that new object. FOREACH gives you the object, but not the block holding it. FORALL will work for this. e.g. blk: reduce [make object! [ test1: 1 ] make object! [ test1: 1 ]] forall blk [ change blk make first blk [test-2: 2] ] probe blk | 16-Jan 19:03 |
| 2736 | Mikesz | I'm trying to add a word to each object in a block of objects with a foreach loop above but it's not working. Can anyone help? | 16-Jan 17:51 |
| 2735 | Mikesz | block-of-objects: reduce [ make object! [ test1: 1 ] make object! [ test1: 1 ]] foreach object-to-edit block-of-objects [ object-to-edit: make object-to-edit [ test-2: 2 ] ] | 16-Jan 16:34 |
| 2734 | Dockimbel | Thanks, I've missed that. In my version, I have removed line 389 in 'split32 and added: fraction: fraction + 1 after 390. That fixes the "by one" inaccuracy. | 7-Jan 23:15 |
| 2733 | Oldes | I transformed both, to-native (the first link) and from-native (second one) although I know the binary to decimal version is not needed for the Red project... it was just to make it complete. Btw.. I think it could be optimised as logic operation are faster than pure math. | 7-Jan 19:47 |
| 2732 | Dockimbel | Hmm, you've transformed 'from-native, but as the real need was in fact to be able to get a binary! representation of a decimal! value, I tranformed 'to-native and 'split for that purpose. Has this IEEE library is quite rich, the need for the workaround of the intermediary string! representation is not needed anymore. Anyway, thanks for the update, I'm sure we'll need it at some point for float support. | 7-Jan 19:03 |
| 2731 | Dockimbel | I've added a +1 in my version to compensate for that. | 7-Jan 18:56 |
| 2730 | Oldes | update: https://github.com/Oldes/rs/commit/19771ea6a7991dd6960ec8c9a1a2a2690c6cd527 fixed the rounding so now the result is same like in the struct! version and added real/from-native32 | 7-Jan 15:49 |
| 2729 | Oldes | But it sometimes returns results which are not exactly identical like with the struct! version... like: #{BDCCCCCC} versus #{BDCCCCCD} for -.1 I guess it's because of rounding error in Rebol itself. | 7-Jan 14:43 |
| 2728 | Oldes | Fine... I just updated the Eric's version: https://github.com/Oldes/rs/commit/37c6e8e8bc316b06bf8eef1638225551421199b2 | 7-Jan 14:40 |
| 2727 | Dockimbel | Got it working for single precision floating points. | 7-Jan 13:40 |
| 2726 | Dockimbel | I should be able to do that, looks easy enough. I'll call you if I get stuck. :-) | 7-Jan 11:01 |
| 2725 | Oldes | I can try to fix the 32bit version if you want.. but later | 7-Jan 10:53 |
| 2724 | Dockimbel | Thanks Oldes, that script should help a lot. | 7-Jan 10:26 |
| 2723 | Oldes | Also Erick's script is only 64bit | 7-Jan 9:52 |
| 2722 | Oldes | Just cannot find the format.r script | 7-Jan 9:47 |
| 2721 | Oldes | you may want to check this one as well: http://www.nwlink.com/~ecotope1/reb/decimal.r | 7-Jan 9:30 |
| 2720 | Louis | Has the esmtp code in rebol core been completely debugged? Is there some documentation somewhere that discusses how to overcome problems is sending e-mail? A script that worked for years can no longer send e-mail, and I have no idea what the problem is. We are using a bluehost server. trace/net on is not revealing the problem. | 7-Jan 4:32 |
| 2719 | Rebolek | yes :) | 7-Jan 0:02 |
| 2718 | Andreas | gues that means "not supported" :) | 6-Jan 23:55 |
| 2717 | Andreas | "2. zakres -0.5 > x > 0.5 nie jest suportowany" | 6-Jan 23:55 |
| 2716 | Andreas | (LGPL) | 6-Jan 23:55 |
| 2715 | Andreas | http://www.rebol.org/view-script.r?script=ieee.r | 6-Jan 23:55 |
| 2714 | Andreas | rebol.org has a binary32 conversion function, but it only seems to be half-done (as far as i can understand) | 6-Jan 23:54 |
| 2713 | Steeve | Nop, I just looked on Rebol.org, nothing around ;-) | 6-Jan 23:54 |
| 2712 | Andreas | i checked the usual sources, yes :) | 6-Jan 23:54 |
| 2711 | Steeve | and you googled everywhere you could I suppose :-) | 6-Jan 23:53 |
| 2710 | Andreas | Asked another way: anyone has decimal to binary ieee754 conversion routines that work on /core handy? | 6-Jan 23:53 |
| 2709 | Andreas | Nope, then I'd ask in another channel :) R2/Core it is. | 6-Jan 23:51 |
| 2708 | Steeve | don't want R3 neither ? | 6-Jan 23:50 |
| 2707 | Andreas | Because it doesn't work on /Core. | 6-Jan 23:49 |
| 2706 | Steeve | Ah! already left | 6-Jan 23:48 |
| 2705 | Steeve | why don't you want ti use struct!, it simple enough ? | 6-Jan 23:46 |
| 2704 | Andreas | Anyone knows of a simple way to get to the binary encoding of a decimal! using just REBOL/Core (i.e. no struct!, no /library)? | 6-Jan 23:13 |
| 2703 | Pekr | Carl is still not apparently available, or he would blog something. | 28-Dec 11:12 |
| 2702 | nve | Any news about a new year version of REBOL ? | 28-Dec 11:00 |
| 2701 | Louis | Oldes, many thanks! I can''t work on this right now, but as soon as I can I'll report back. | 27-Dec 0:12 |
| 2700 | Oldes | (it could be probably optimized as the script is from year 2004, but I don't care too much) | 26-Dec 20:39 |
| 2699 | Oldes | I have uploaded my latest EXIF-parser version at github - https://github.com/Oldes/rs/blob/master/projects/exif-parser/latest/exif-parser.r To sort files you can use for example: dir: %/e/DCIM/100CANON/ t: now/time/precise result: copy [] foreach file read dir [ error? try [ ctx-exif/parse-file dir/:file exifdate: ctx-exif/get-tag-value 306 repend result [exifdate dir/:file] ] ] sort/skip result 2 print ["sorted" (length? result) / 2 "files in" now/time/precise - t] result ;>>sorted 120 files in 0:00:00.153 | 26-Dec 20:35 |
| 2698 | Pekr | Dunno how fast it is going to be though, exiftool looks slow, when called from REBOL. Might take some time to extract info from xy files in directory ... | 26-Dec 18:15 |
| 2697 | Louis | Wow! Thanks for the help Pekr! | 26-Dec 18:13 |
| 2696 | Pekr | your value is in EXIF-create-date .... | 26-Dec 15:35 |
| 2695 | Pekr | parse/all buff [thru "Create Date" thru ": " copy EXIF-create-date to newline] | 26-Dec 15:34 |
| 2694 | Pekr | works like a charm, returning several pages of txt formatted output - http://www.sno.phy.queensu.ca/~phil/exiftool/ | 26-Dec 15:26 |
| 2693 | Pekr | >> buff: copy "" >> call/wait/output "exiftool img_0033.jpg" buff | 26-Dec 15:25 |
| 2692 | Pekr | or you can use command line tool like Exiftool, and wrap the result using CALLL in REBOL and parse the output? | 26-Dec 15:23 |
| 2691 | Pekr | There are two scripts from Piotr Gapinski, related to EXIF. IIRC Oldes did ImageMagick wrapping,maybe it can do some EXIF stuff too ... | 26-Dec 15:16 |
| 2690 | Louis | Pekr, thanks for responding. I'll look there. | 26-Dec 15:06 |
| 2689 | Pekr | IIRC, someone did EXIF reader. Have you tried looking into rebol.org? | 26-Dec 15:05 |
| 2688 | Louis | a function to sort jpeg files from a digital camea by exif date? | 26-Dec 14:27 |
| 2687 | Louis | Does anyone have | 26-Dec 14:26 |
| 2686 | Endo | Oh sorry, your second example. Ok. | 20-Dec 11:50 |
| 2685 | Endo | In your example above it shifts bytes not bits. Even shifting bits in binary without carrying bits over to the next bytes doesn't look useful. | 20-Dec 11:49 |
| 2684 | Geomol | My example is doing bit shifting right (decreasing value) by 2 bits at a time. The bits falling off each byte isn't carried over to the next byte. | 20-Dec 11:43 |
| 2683 | Endo | Its no sense SHIFTing bytes in binary, we can simply use series functions, append #{00}, copy/part etc. Shifting bits in binary could be more useful for graphics operations (not so sure) | 20-Dec 11:32 |
| 2682 | Geomol | What's the idea with SHIFTing a binary! ? >> b: #{80402010} == #{80402010} >> shift b 2 == #{20100804} >> shift b 2 == #{08040201} ; so far so good >> shift b 2 == #{02010000} ; but now we're loosing information >> shift b 2 == #{00000000} So SHIFT of a binary! just shift each byte and don't carry bits over to the next. What is this used for? | 19-Dec 23:52 |
| 2681 | Geomol | Hm, implementing SHIFT in World gives me second thought. The C operators >> and << works as doing internal modulus. So checking for number of shift will hit on performance. So it's probably better to just go with it and let it be up to the user to eventually check for this. | 19-Dec 21:33 |
| 2680 | Endo | As for R2, its no problem, but for others it is. | 19-Dec 14:15 |
| 2679 | Endo | That's right, but only if your "interpreter" supports 64 bit integers. | 19-Dec 14:15 |
| 2678 | Geomol | And the mod by 32 for a rotate is only ok on a 32-bit system, on a 64-bit it's mod by 64. And only for integers, not binaries etc. | 19-Dec 14:09 |
| 2677 | Geomol | Think what will happen, if the application move from 32-bit to 64-bit. | 19-Dec 14:06 |
| 2676 | Geomol | I see potential application malfunction. It's ok to mod by 32 for a rotate function, as it gives same result, but not a shift, I think. | 19-Dec 14:05 |
| 2675 | Endo | at first glance a bit confusing, but actually it's ok. >> shift 257 65 == 128 | 19-Dec 14:04 |
| 2674 | Endo | >> shift 257 32001 == 128 >> shift 257 1 == 128 | 19-Dec 14:03 |
| 2673 | Endo | Yes | 19-Dec 14:02 |
| 2672 | Geomol | which is same result as: >> shift 257 32000 // 32 == 257 | 19-Dec 14:02 |
| 2671 | Endo | >> shift 257 32000 == 257 | 19-Dec 14:01 |
| 2670 | Endo | Thats right I think: >> shift 257 32 == 257 | 19-Dec 14:01 |
| 2669 | Geomol | Ah, probably just because 32 is being // 32, as can be seen with this: >> shift 2 32 == 2 >> shift 2 33 == 1 | 19-Dec 14:00 |
| 2668 | Geomol | Is there a reason for this? >> shift 1 32 == 1 | 19-Dec 13:56 |
| 2667 | Oldes | But I'm not sure there is anybody left who can fix it. | 19-Dec 13:19 |
| 2666 | Oldes | The doc above is not so bad, but it's true, that in R3 it's really marked as: (Modifies) | 19-Dec 13:19 |
| 2665 | Oldes | The behaviour is correct (it's not just replace/all). The dictionary must be bad as it does not modify. | 19-Dec 13:16 |
| 2664 | Oldes | == "^-ab^-def" >> detab s == " ab def" | 19-Dec 13:15 |
| 2663 | Geomol | The R2 dictionary for DETAB say, the string is modified, but it isn't. Also only the first tab before the first non-space character is replaced by 4 spaces, the rest with 1: >> s: "^-abc^-def" == "^-abc^-def" >> detab s == " abc def" >> s == "^-abc^-def" Has this always been this way? Doc: http://www.rebol.com/docs/words/wdetab.html | 19-Dec 13:12 |
| 2662 | Geomol | That wasn't clear, but good you solved your problem. | 18-Dec 15:36 |
| 2661 | amacleod | enbase! Easy! That's what I'm looking for thanks, guys. | 18-Dec 15:35 |
| 2660 | Gabriele | ENBASE | 18-Dec 15:27 |
| 2659 | Geomol | Notice the molded version is twice as large as the original binary. | 18-Dec 14:15 |
| 2658 | Geomol | x: mold 64#{
/9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa
AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
is3eIoxUdG7n/9k=
} copy/part skip x 3 -5 + length? x | 18-Dec 14:14 |
| 2657 | amacleod | I need to extract the data from an image file so it does not include the "64#" header and I just have the 64 bit encoding: 64#{ /9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp is3eIoxUdG7n/9k= } I just wnat the stuff between the quotes but as its a binary I can't seem to parse it or extract it with other methods like a text file. | 18-Dec 14:07 |
| 2656 | Ladislav | see http://issue.cc/r3/1634 | 17-Dec 12:24 |
| 2655 | Ladislav | In R3 also: >> print mold/all to decimal! #{4013 FFFF FFFF FFFF} 4.9999999999999991 >> print mold/all to decimal! #{4014 0000 0000 0000} 5.0 >> print mold/all to decimal! #{4014 0000 0000 0001} 5.0000000000000009 | 17-Dec 12:11 |
| 2654 | Geomol | In R2, you can do some rounding before calling unique. | 17-Dec 11:10 |
| 2653 | Geomol | In R3, you can try do a >to binary!< on the results from the calculation and see the difference. | 17-Dec 11:10 |
| 2652 | Henrik | it works in R3. | 17-Dec 11:03 |
| 2651 | Geomol | It's internal rounding in REBOL, is my guess. You can see it with R3: >> to decimal! #{4013 FFFF FFFF FFFF} == 5.0 >> to decimal! #{4014 0000 0000 0000} == 5.0 >> to decimal! #{4014 0000 0000 0001} == 5.0 So decimals may look the same, even if they're not. | 17-Dec 11:01 |
| 2650 | Henrik | Seems it's already been repported: http://www.rebol.net/cgi-bin/rambo.r?id=4093& | 17-Dec 10:58 |
| 2649 | Henrik | YY is a block of 4 decimals, which should be containing the same value, but it seems they are not the same to UNIQUE: == [5.0 5.0 5.0 5.0] ; derived from a calculation >> yy/1 == yy/2 == true >> yy/1 == yy/3 == true >> yy/1 == yy/4 == true >> unique yy == [5.0 5.0] ; huh? >> zz: [5.0 5.0 5.0 5.0] ; typed directly in >> unique zz == [5.0] | 17-Dec 10:56 |
| 2648 | Gabriele | Qtask does not depend on any changes being made to REBOL. | 17-Dec 9:53 |
| 2647 | Henrik | "Since Carl seems to have abandoned Rebol" - there is no evidence of that. A few weeks ago, it was stated here that Carl was working on R3 again. | 17-Dec 9:30 |
| 2646 | PeterWood | He may well know but I think that it is wishful thinking that the source may be released under an escrow agreement just because Carl has been quiet for a while. | 17-Dec 9:27 |
| 2645 | GrahamC | I wonder if Reichart knows ... Qtask depends on Rebol | 17-Dec 4:02 |
| 2644 | Sunanda | That would depend on what the escrow license says. Unless anyone here has signed a REBOL escrow source license, all we have is a vague description: http://www.rebol.com/faq.html#058 | 17-Dec 0:42 |
| 2643 | GrahamC | Since Carl seems to have abandoned Rebol ...I wonder if this triggers the release of the source code held in escrow? | 16-Dec 23:49 |
| 2642 | Endo | which means 10 times better than mine :) its normal to have that performance with 8GB RAM + SSD I think. file & block operations & foreach is fast on R2 in my experience. | 16-Dec 13:20 |
| 2641 | Ashley | iCore 7 with 8GB RAM and a 256GB SSD ... work PC. | 16-Dec 12:40 |
| 2640 | Endo | I do something similar, generating 10'000 lines and writing to a file takes 5-6 seconds to complete on my Intel Core 2 Duo E7400 (2.8 Ghz) 3GB RAM. 500'000 lines a bit too much but you read the whole file into memory so it is possible. Your PC is a good one as well I think. | 15-Dec 14:43 |
| 2639 | Ashley | R2. | 15-Dec 12:51 |
| 2638 | BrianH | R2 or R3? R3 can do removes from the head of the string as fast as it can from the tail - near instantaneously. I don't think that this is true for R2. | 14-Dec 21:33 |
| 2637 | Ashley | It certainly worked (file size was 400MB not 600MB). | 14-Dec 21:03 |
| 2636 | Geomol | Does it work? Or do you hit a 4GB boundary with some internal structures, so there is an error, you don't get out? | 14-Dec 11:05 |
| 2635 | Ashley | Ran code like the following against a 600MB file of 500,000+ lines: file: read/lines %log.csv foreach line file [ remove/part line 1000 ] and was surprised that the foreach loop was near instantaneous (I'd assumed 500,000+ removes would at least take a second or two). I'm not complaining, just curious. ;) | 14-Dec 10:02 |
| 2634 | Kaj | It would depend on the relative speeds of the CPU and the FPU | 12-Dec 15:06 |
| 2633 | Sunanda | I see the log-10 loop as around 18% faster under core 2.7.8. So this optimisation depends, it seems, on specific machines and versions. | 12-Dec 15:02 |
| 2632 | Geomol | >> number: 1234
== 1234
>> time [loop 1000000 [1 + to integer! log-10 number]]
== 0:00:00.293239
>> time [loop 1000000 [length? form number]]
== 0:00:00.28022 On R2 version 2.7.7.2.5 | 12-Dec 12:48 |
| 2631 | Ladislav | "but that's slightly slower than yours, it seems" - strange, here it looks much faster than length? form | 12-Dec 12:32 |
| 2630 | Geomol | :) | 10-Dec 15:08 |
| 2629 | Henrik | I may have found another way without needing to work on the length. Thanks, anyway. | 10-Dec 15:08 |
| 2628 | Geomol | Then mine won't work. | 10-Dec 15:07 |
| 2627 | Henrik | it's most likely to be a decimal | 10-Dec 15:06 |
| 2626 | Geomol | Can your number both be integer and decimal? | 10-Dec 15:06 |
| 2625 | Geomol | My guess would be: 1 + to integer! log-10 number , but that's slightly slower than yours, it seems. | 10-Dec 15:05 |
| 2624 | Henrik | what is the fastest way to find the number of digits in a number, if you want to use it to calculate the pixel width of the number for a table column? simply using: length? form number ? | 10-Dec 14:58 |
| 2623 | Henrik | Thank you very much. I forgot that. | 7-Dec 15:43 |
| 2622 | Dockimbel | dehex | 7-Dec 15:41 |
| 2621 | Henrik | if I have a file with url-encoded chars in it, what's the fastest way to decode them? | 7-Dec 15:40 |
| 2620 | amacleod | It's enabled but does not sync as fast as the drift and I'm having trouble doing it manually...keep getting an error and I tried several time servers. | 30-Nov 20:19 |
| 2619 | BrianH | The hardware clocks of many computers are rather inaccurate, though they're getting better.. They expect you to enabe the time sync services. | 30-Nov 19:05 |
| 2618 | BrianH | It might be better to enable your server's native time sync services. Windows, Linux and OSX all have such services, as do many more OSes. | 30-Nov 19:03 |
| 2617 | amacleod | daytime://nist1.aol-va.symmetricom.com seems to work resonably well I dont need to be too accurate just +- 5 seconds.... my server's time seems to be drifting. I've seen this before on an another computer...does a bad battery affect the time even if the power remains on? | 30-Nov 16:15 |
| 2616 | Pavel | size = site | 30-Nov 15:49 |
| 2615 | Pavel | 2 amacleod: time protocol is not very accurate, the same levely of accuracy you can get by reading any HTML size and distile the time from HTML header. OTOH NTP protocol is able to get milisecond accuracy but by quite difficult handshake and as far as I know not yet written for rebol | 30-Nov 15:49 |
| 2614 | BrianH | There are a few different time protocols, and the standard time servers don't tend to run the daytime protocol. They usually run NTP. | 30-Nov 15:33 |
| 2613 | amacleod | I'm trying to reach a time server but having trouble.
I can get a time from my rebol based time server on my server with "read daytime://myserver.com" but if I use it for any of the well known online servers I get : >> read daytime://time-b.nist.gov == "" >> read daytime://nist1-ny.ustiming.org == "" sometimes it seems to work but more often than not I get an empty string | 30-Nov 15:22 |
| 2612 | amacleod | right..... | 16-Nov 2:11 |
| 2611 | Henrik | you would need an ALL instead of ANY in the first one, if it is to behave like the bottom one. | 15-Nov 21:15 |
| 2610 | amacleod | why does this not work: unless any [exists? file1 exists? file2 exists? file3][print "missing file"] but this does: if any [not exists? file1 not exists? file2 not exists? file3][print "missing file"] | 15-Nov 21:08 |
| 2609 | Gabriele | Linux also would not consider them equivalent. I understand why Mac OS is always canonicizing file names, but, they chose the most stupid way to do it, and it's a pain in the ass most of the time. In the end, I prefer Linux where you can end up with two files named in a way that looks exactly the same, but that has a file system that behaves in a predictable way. | 12-Nov 13:43 |
| 2608 | Ladislav | I want to share with you an "interoperability problem" I encountered. In Windows (at least in not too old versions) there are two versions of string-handling functions: - ANSI (in fact using a codepage for latin charset) - widechar (in fact UNICODE, restricted to 16 bits, I think) It looks, that Apple OS X "prefers" to use decomposed UNICODE, also known as UTF-8MAC, I guess. That means, that it e.g. for a Robert's file it generates a filename looking (in a transcription) as follows: %"Mu^(combining-umlaut)nch.r" As far as the UNICODE goes, this is canonically equivalent to %"M^(u-with-umlaut)nch.r" , but: - Windows don't consider these file names equivalent, i.e. you can have both in one directory - When using the former, the ANSI versions of Windows system functions "translate" the name to: %"Mu^(umlaut)nch.r" -- the %"Mu^(umlaut)nch.r" is a third file name, distinct from both of the above, so, if the R2 reads it in a directory, it is unable to open it | 11-Nov 14:59 |
| 2607 | BrianH | Oldes, the char! type in R3 refers to a Unicode codepoint, not a character. So, length still doesn't apply. | 10-Nov 16:24 |
| 2606 | Geomol | It probably won't add overhead to length?, because that function already works with different datatypes, and char! is just another one in the switch already there. | 10-Nov 12:46 |
| 2605 | Oldes | I can imagine length? on char! value in unicode context - it could return number of bytes needed to store the char with the utf-8 encoding:) But I'm sure I can live without it. It would just add overheat to the length! action. | 10-Nov 11:26 |
| 2604 | Gabriele | But, there are so many other ways to use them. For example, to implement a bloom filter: http://en.wikipedia.org/wiki/Bloom_filter | 10-Nov 10:33 |
| 2603 | Gabriele | Geomol, because of Unicode, "charset kind of bitsets" need more than 256 bits. | 10-Nov 10:32 |
| 2602 | BrianH | intexes -> indexes | 9-Nov 16:07 |
| 2601 | BrianH | Bitsets are useful for intexes and certain kinds of parsing (LL first and follow sets, not just character sets). Other stuff too. | 9-Nov 16:07 |
| 2600 | Geomol | Yes, but that's the charset kind of bitset. I guess, other kinds of bitsets (other lengths than 256) can be used just to hold a bunch of flags or something. I haven't seen them used like that. | 9-Nov 16:02 |
| 2599 | Sunanda | <Other uses of bitsets> One use is conformity validation. eg: allowed-letters: charset [#"a" - #"e"] find allowed-letters "aaadddeeebbb" == true find allowed-letters "aaadddeeebbbx" == none | 9-Nov 16:00 |
| 2598 | Andreas | (Bitsets are vastly more useful in R3.) | 9-Nov 15:54 |