| # | User | Message | Date |
| 9898 | Steeve | Thanks | 23-Jan 20:55 |
| 9897 | Ladislav | this looks more likely: defined?: either rebol/version >= 2.100.0 [ func [ {find all defined words in the given context} context [any-object!] /local words ][ words: words-of context remove-each word words [not value? word] words ] ][ func [ {find all defined words in the given context} context [object!] /local words ][ words: bind first context context remove-each word words [not value? word] words ] ] | 23-Jan 20:23 |
| 9896 | Ladislav | ah, bad code, needs correction | 23-Jan 20:20 |
| 9895 | Ladislav | defined?: func either rebol/version >= 2.100.0 [[ {find all defined words in the given context} context [any-object!] /local words ]][[ {find all defined words in the given context} context [object!] /local words ]][ words: first context remove-each word words [not value? word] words ] | 23-Jan 20:17 |
| 9894 | Oldes | I should try it first, my mistake. | 23-Jan 19:48 |
| 9893 | Oldes | Ah.. I see... the defined? function is not defined:) | 23-Jan 19:47 |
| 9892 | Steeve | I suspect something odd ;-) | 23-Jan 19:29 |
| 9891 | Steeve | Ok ok, but I just want to have a look on the functions Cyphre pointed out :) | 23-Jan 19:28 |
| 9890 | Oldes | (of course without the init part - that was for my personal use) it's pretty old script, I almost forgot I have it:) | 23-Jan 19:25 |
| 9889 | Oldes | >> gbl-test [ o: context [a: 1] ] == [o] >> gbl-test [ o: context [a: 1 set 'b 2] ] == [b o] | 23-Jan 19:23 |
| 9888 | Oldes | The above script I was using to detect leaking variables | 23-Jan 19:22 |
| 9887 | Oldes | Steeve... I guess Ladislav is looking for something like this R2 helper script: gbl-test: func [ code /all /init {returns string with all global variables set to none} /local gbl-list words str_init ][ words: make block! 50 str_init: make string! 1000 gbl-list: query/clear system/words do code if block? gbl-list: query system/words [ foreach item gbl-list [ if any [all value? item] [ insert tail words to-word item if init [ insert tail str_init join to-word item ": " ] ] ] ] if init [ write clipboard:// join str_init "none" ] words ] >> gbl-test [a: 1] == [a] >> f: func[a][b: a + 1] gbl-test [f a: 1] == [a b] | 23-Jan 19:21 |
| 9886 | Steeve | Still I wonder, what is the so called defined? function ? Where can I find it ? | 23-Jan 19:12 |
| 9885 | Ladislav | However, I do not track "modified", since that is a bit more complicated/slower than I like. | 23-Jan 18:39 |
| 9884 | Ladislav | Terminological problem, yes | 23-Jan 18:38 |
| 9883 | Steeve | "newly-defined" is confusing :-) | 23-Jan 18:36 |
| 9882 | Steeve | ok | 23-Jan 18:35 |
| 9881 | Steeve | You want to track the "modified" words, right ? | 23-Jan 18:35 |
| 9880 | Ladislav | I originally pointed out how implemented the functionality in R2 (using the query/clear system/words expression. | 23-Jan 18:35 |
| 9879 | Steeve | I probably mistaken the words "newly-defined" for "newly-created" | 23-Jan 18:34 |
| 9878 | Ladislav | typo: "Can the source of INTERN help me with that? | 23-Jan 18:31 |
| 9877 | Ladislav | What I (essentially) want is described in the help string: {do the given BLOCK and find the newly-defined words} Can the source of INTERN cannot help me with that? | 23-Jan 18:31 |
| 9876 | Steeve | Its tracking newly "created" words in the user context after a binding. It's maybe not what you're trying to do but it was in response to Cyphre. | 23-Jan 18:28 |
| 9875 | Ladislav | I may be completely missing the point, Steeve. How exactly can the source of the INTERN function help with detection? | 23-Jan 18:24 |
| 9874 | Steeve | Cyphre, it's not a good approach in R3 To track newly defined words in a context you can check the source of the function INTERN. | 23-Jan 18:04 |
| 9873 | Cyphre | Ladislav, I think you already wrote something like that for R3? newly-defined?: func [ {do the given BLOCK and find the newly-defined words} block [block!] /local old ] [ old: append append defined? system/contexts/lib defined? system/contexts/sys defined? system/contexts/user do block exclude defined? system/contexts/user old ] | 23-Jan 17:16 |
| 9872 | Ladislav | Well, it is not a big "disaster" for me, since it is not too hard for me to adjust the function I am writing for R3 with just a slight modification of the behaviour... | 22-Jan 18:37 |
| 9871 | BrianH | Now that you mention it, I'm wondering that too. There isn't any tracking of state changes for R3 objects that I'm aware of, and there's nothing like system/words. | 22-Jan 18:35 |
| 9870 | Ladislav | Wondering if there is an analogy of query/clear system/words | 22-Jan 18:27 |
| 9869 | Steeve | Any info about the algorithms used to construct and perform lookup on symbol's tables in R3 ? People gave some hints back in the day. But I can't remember who. | 29-Dec 10:06 |
| 9868 | Robert | But R3 can't deal very good with multi-threaded libs. You need to trick it: Use async with non or integer value to trigger a sync call on Rebol side. | 11-Dec 21:59 |
| 9867 | BrianH | Still, a generator of marshalling wrapper functions would be nice, especially since REBOL and C don't have similar data models. | 11-Dec 20:50 |
| 9866 | BrianH | With R3 you can just callback functions if you want a synchronous call, or callback through an event if you want to go asynchronous. | 11-Dec 20:45 |
| 9865 | Kaj | I've bound the standard C math library already, but it's waiting for the floats | 11-Dec 19:14 |
| 9864 | Marco | Right. Red/System seems vary nice. I am waiting for floats to be implemented in Red/System. Is there a "math" library that could be used intead? | 11-Dec 19:13 |
| 9863 | Kaj | Red/System has native callbacks already. I'm using them in most library bindings | 11-Dec 19:10 |
| 9862 | Marco | display: make callback! [...] [...] glutDisplayFunc :display | 11-Dec 18:48 |
| 9861 | Geomol | Do you have a simple example? | 11-Dec 18:08 |
| 9860 | Marco | wish for R3 / Topaz / Red / World: callback! datatype so you can "really" use a lot of nice shared libraries. | 11-Dec 18:03 |
| 9859 | BrianH | The particular error triggered in the Windows console when you try to make a directory with only periods in its name is that the directory already exists; this is probably a bad error. However, when you try to MAKE-DIR directories that already exist in REBOL, it's a noop, not an error. That is probably why it's not triggering an error here. | 5-Dec 16:21 |
| 9858 | Henrik | It is possible to make this directory under OSX, as far as I can see. | 5-Dec 15:49 |
| 9857 | BrianH | This may be unrelated though. | 5-Dec 15:34 |
| 9856 | BrianH | There is a cross-platform bug in R3 where it won't see any file or directory that starts with two periods, not just . and .. - the ticket: http://issue.cc/r3/1899 | 5-Dec 15:33 |
| 9855 | Endo | When I trace it, it "sees" the error but returns the path: ... Trace: return (word) Trace: path (word) Result: (error) Result: (error) Result: (error) Result: %.../ (file) | 5-Dec 14:14 |
| 9854 | Pekr | When I try to make three dot dir under Vista, it returns an error, and hence R3 hould return an error too imo. Ditto for invalid chars, not allowed being a part of the dir names ... | 5-Dec 12:05 |
| 9853 | Henrik | Do you think this is a bug? | 5-Dec 11:04 |
| 9852 | Henrik | Neither R2 nor R3 considers it to be a problem making this directory in WinXP: make-dir %.../ but the directory is never made, as far as I can tell. Doing it from a command prompt returns that the directory already exists. | 5-Dec 11:04 |
| 9851 | Kaj | R3 is typically about a third faster than R2 in my tests on Linux, even with my CMS that mostly does text processing | 3-Dec 2:53 |
| 9850 | Geomol | Could be. I need pragmas in a few places, but I haven't dug deeply into that area of compilation. It's boring, I think. :) And I haven't had time to look at things like LLVM, but that would probably solve some problems and speed things up even more. | 2-Dec 19:37 |
| 9849 | BrianH | Seems that could be tweaked with pragmas, right? | 2-Dec 19:33 |
| 9848 | Geomol | I guess, it has something to do with, how lucky the compiler is maybe to get data on 64bit boundaries and make code parts/data fit in cache and such technical things. | 2-Dec 19:32 |
| 9847 | Geomol | Using gcc, I experience up to 33% changes in some tests from compilation to compilation, so that could be. | 2-Dec 19:30 |
| 9846 | BrianH | There are a lot of problems with R3 on OSX, and different problems with R2. Annoying. | 2-Dec 19:29 |
| 9845 | BrianH | Well, that isn't affected by any of the standard slowdowns. I wonder if it's an issue with the difference in C compilers between the two versions. | 2-Dec 19:28 |
| 9844 | Geomol | R2: >> system/version == 2.7.7.2.5 R3: >> system/version == 2.100.111.2.5 | 2-Dec 19:27 |
| 9843 | Geomol | My R2 time is: time: func [:f /local t][ t: now/time/precise do f now/time/precise - t ] | 2-Dec 19:26 |
| 9842 | Geomol | Under OS X: Using R2: >> time [n: 1000000 while [0 < n: n - 1][]] == 0:00:00.219887 Using R3: >> dt [n: 1000'000 while [0 < n: n - 1][]] == 0:00:00.339793 | 2-Dec 19:25 |
| 9841 | Steeve | console | 2-Dec 19:24 |
| 9840 | BrianH | It should be if you are doing the loop directly from the console or otherwise using a object/module/script/closure context rather than in a function. | 2-Dec 19:24 |
| 9839 | Steeve | I tested the loop example given by Geomol. Same speed more or less.in R2 and R3 | 2-Dec 19:21 |
| 9838 | Steeve | AFAIK, R3 always has been faster or equal in the early tests I made, that's why I don't understand the current situation. | 2-Dec 19:20 |
| 9837 | BrianH | I haven't compared operator evaluation yet, which was another major change between R2 and R3. Overall, R3 looks a little worse for C-like code than R2, though neither are really appropriate for that kind of thing. And yet in my tests (which I don't have the results of handy, so take that with a grain of salt) idiomatic R3 is faster than idiomatic R2 for REBOL-like tasks, and the R3 idioms are less awkward to write than the R2 idioms. How have the rest of you found the differences to be in your work? | 2-Dec 19:07 |
| 9836 | BrianH | (This is continued from #World, where it was a little off-topic) | 2-Dec 19:01 |
| 9835 | BrianH | R3 operations that would be slower than R2: - Bulk string handling, because strings are twice as big (Unicode). - Word dereferencing for function-context words, because they are stack-relative, adding an indirection. - The fixed overhead of LOAD (like header handling) because it does a lot more. Any others? | 2-Dec 18:58 |
| 9834 | BrianH | One thing you might have to consider with your refinement suggestion is that you would have to put a lot of parentheses around function calls, because otherwise your syntax would make it ambiguous which function the refinement applies to. This is similar to the situation with Smalltalk and Objective-C. | 26-Nov 20:13 |
| 9833 | BrianH | Macros make a lot more sense in compiled languages like Red, Topaz (to JS) and World (to bytecode) than they do in interpreted code-is-data-at-runtime languages like R3, where most functions are like macros. | 26-Nov 20:10 |
| 9832 | BrianH | Make your own then :) I'm not blowing you off, it's a real suggestion. | 26-Nov 20:09 |
| 9831 | Marco | Topaz options are nice but not nicer for my tastes. | 26-Nov 20:07 |
| 9830 | BrianH | You might want to check out the way Topaz does function options - it's even better than that :) | 26-Nov 20:06 |
| 9829 | Marco | wish for R3 / Topaz / Red / World:
I wish that refinements would be totally reworked (not R2 compatible :( ). Current situation with some examples: view/new/title/offset/options win "Dialog" 20x20 'resize remove_last: func [{remove last (n) element(s) of a series} serie [series!] /n num [integer!] ][ num: any [num 1] remove/part skip tail serie negate num num ] append: func [{Appends a value to the tail of a series and returns the series head.} series [series! port!] value /only ][ head either only [ insert/only tail series :value ] [ insert tail series :value ] ] New situation with different syntax and default values: view win /new true /title "Dialog" /offset 20x20 /options 'resize remove_last: func [{remove last (n) element(s) of a series} series [series!] /n: 1 [integer!] ][ remove skip tail series negate n /part n ] append: func [{Appends a value to the tail of a series and returns the series head.} series [series! port!] value /part /only /dup ][ head insert tail series :value /part part /only only /dup dup ] Note that append could also be redifined as: #macro append [] [head insert tail] | 26-Nov 20:04 |
| 9828 | BrianH | sorry, that second system/contexts/lib was supposed to be system/contexts/sys. | 26-Nov 20:01 |
| 9827 | BrianH | The main global contexts are system/contexts/lib, system/contexts/lib and the module contexts. All non-private modules are just as global as lib and sys. | 26-Nov 20:01 |
| 9826 | BrianH | Modules extend the system object, in particular system/contexts/lib (aka lib), and the per-task (as planned) context system/contexts/user gets its values from there. The system object is actually going to be per-task, referencing global objects through system/contexts/*. | 26-Nov 19:58 |
| 9825 | Marco | The Rebol system object is a very nice thing. I would pack it with all sort of things, especially those that can be "global" to a program or even "global" to many Rebol programs. | 26-Nov 19:55 |
| 9824 | BrianH | R3 PARSE rules can reference charsets and rules from path references, so they don't even have to be exported as raw words. | 26-Nov 19:53 |
| 9823 | BrianH | No need to add them to the system opject in R3, just export them from a module and they'll be available. They should be made read-only for security, but this is a good idea. | 26-Nov 19:52 |
| 9822 | Marco | wish for R3 / Topaz / Red / World: Add common charsets and parsing rules to system object: system/parse: context [ digit: charset [#"0" - #"9"] upper: charset [#"A" - #"Z"] lower: charset [#"a" - #"z"] alpha: union upper lower hexdigit: union digit charset "abcdefABCDEF" bindigit: charset "01" space: charset " ^-^/" digits: [some digit] decimal: [opt digits "." digits | digits "." ] exponent: [ [ "e" | "E" ] opt ["+" | "-"] digits] float: [opt "-" [decimal | digits] opt exponent] email:... ...etc. ] | 26-Nov 19:50 |
| 9821 | BrianH | There's no easy way to add an MP3 type yet, because there's no audio type concept in R3 yet. But .jpg is supported already. | 26-Nov 19:49 |
| 9820 | BrianH | R3 has that (codecs), but we would welcome any suggestions you would have for making them easier to use. | 26-Nov 19:47 |
| 9819 | Marco | wish for R3 / Topaz / Red / World: Add possibility to extend "read" and "load" to let them transparently load also custom file types (.tiff, .mp3 etc.) Use something like: system/mime: context [ JPG: context [ extensions: [%.jpg %.jpeg ...] header: #{JFIF} open: func [...] read: func [...] load: func [...] save: func [...] write: func [...] close: func [...] ] ... ] | 26-Nov 19:46 |
| 9818 | BrianH | Nope, still post them here. We still work on R3, and some of us use it professionally. | 26-Nov 19:40 |
| 9817 | Henrik | ok, good. | 23-Nov 11:54 |
| 9816 | ChristianE | Not, but you've reversed the order of plain and bold in the test for R3 :D So, it's 27x14 for bold and 26x14 for plain text, actually. | 23-Nov 11:53 |
| 9815 | Henrik | Really? So, the bold font is *smaller* than the plain font? | 23-Nov 11:49 |
| 9814 | ChristianE | R3 2.100.110.3.1 on Win 7 gives 27x14 for plain and 26x14 for bold text (both 1x0 bigger than yours). | 23-Nov 11:49 |
| 9813 | Henrik | A test of SIZE-TEXT shows a bug in R2. This should hopefully not be present in R3. The test to run: f: make system/standard/font [name: "Verdana" size: 12] g: make gob! [] t: import 'text g/text: bind [font f bold true text "Boo"] t probe size-text g ; I get 26x14 here g/text: bind [font f bold false text "Boo"] t probe size-text g ; I get 25x14 here It's possible that the result may vary, but the bold version should produce a wider size than the normal one. if you can test this similarly to what you did for R2, that would be great. Thanks. | 23-Nov 11:27 |
| 9812 | sai hua | hello | 22-Nov 2:49 |
| 9811 | sai hua | hello | 22-Nov 2:49 |
| 9810 | BrianH | I was talking about http://issue.cc/r3/1834 but that's good to hear too :) | 11-Nov 20:09 |
| 9809 | Ladislav | "Ladislav is the one who would likely be doing the work, and he seems to need some convincing" - I do agree, that LESSER? etc. functions having two versions (or a refinement, or something) would be useful. | 11-Nov 14:44 |
| 9808 | BrianH | Andreas, given that Carl is one of the ones who was tripping over the equivalence hierarchy (that he helped decide on) that ticket looks pretty promising. The caveat is that Ladislav is the one who would likely be doing the work, and he seems to need some convincing. Plus, it would require a new R3 release, not just a host kit update. | 10-Nov 17:58 |
| 9807 | BrianH | The STRICT-* relative comparison functions wouldn't have operators, unless we could come up with some that don't look like line noise (or worse: Perl). | 10-Nov 17:51 |
| 9806 | BrianH | The term "relative comparison hierarchy" may be better, since it wouldn't include NOT-EQUAL? and such. | 10-Nov 17:49 |
| 9805 | Andreas | "Nicely fit with an inequality comparison hierarchy", of course. Bad typing day, I guess. | 10-Nov 17:41 |
| 9804 | Andreas | I think that would nicely fit with a inequality comperison hierarchy as well (strict vs non-strict). | 10-Nov 17:40 |
| 9803 | Andreas | We have a ticket for an improved equality comparison hierarchy: http://www.curecode.org/rebol3/ticket.rsp?id=1834 | 10-Nov 17:39 |
| 9802 | BrianH | Perhaps the relative comparison functions could be made to all be case-insensitive (for datatypes that have case defined as a concept), and have additional STRICT-* case-sensitive functions which would combine the functions and STRICT-NOT-EQUAL?. | 10-Nov 17:31 |
| 9801 | BrianH | Too bad we don't have a hierarchy of inequalities. Only two levels would be needed. Maybe a /case option to the functions that the the operators map to? Is it even possible to map an op! to a function that can take an option? | 10-Nov 17:22 |
| 9800 | BrianH | I don't like this inconsistency though: >> "a" > "A" == false >> #"a" > #"A" == true | 10-Nov 17:17 |
| 9799 | BrianH | Now this looks completely weird:
>> #"a" + #"b"
== #"A" Having ordinal values that you wouldn't think of being numbers act like numbers seems really weird to me. I can accept that #"a" > #"A", but treating them like numbers without explicit conversion seems strange to me. I get similarly creeped out by multiplying one money! by another; I have to remember that despite the "$", and "money!" name, they aren't really money (a measure of quantity), they are just another numeric encoding that enables more precise decimal math than decimal! (another name that seems off to me, since its values are floating-point binary, not decimal). | 10-Nov 17:15 |
| 9798 | BrianH | Alright, not "most of the time", just in this case. For others:
>> 1 + 1.0
== 2.0
>> 1 + $1
== $2
>> 1 + 100%
== 2.0 Maybe that's why it seems weird. I guess that since R3 char! values are currently limited to the codepoints in the BMP they are 16 bits, so converting back to char! would be a potential loss of range. It could go either way, so I guess the datatype-on-the-left rule is a way for the developer to specify which they want. And that rule applies to string types too (for INSERT and APPEND), so it's not completely weird. | 10-Nov 17:06 |
| 9797 | BrianH | For instance:
>> 1 + #"a"
== 98
>> #"a" + 1
== #"b" The latter looks alright to me, the former looks weird, like a to-integer is missing. Can't say why though. I know why the result is an integer! (the left side sets the datatype returned most of the time), but any math that treats a char! as a number rather than as a non-numeric ordinal value just seems weird to me. | 10-Nov 16:55 |
| 9796 | BrianH | In general, doing math with char! values without explicitly converting them is kind of bad form; it leads to developer confusion. The main reason you'd do this is because of the awkwardness of combining operator and prefix expressions without parentheses. It's interesting that it still works in some cases, but not in others. Considering characters to be number-like is a bit weird, a bit too C-like for my tastes. | 10-Nov 16:50 |
| 9795 | Geomol | The last is only confusing, if chars are considered string-like, as in R3. In R2, #"a" being greater than #"A" makes good sense. | 10-Nov 16:49 |
| 9794 | BrianH | There was a big debate about this before we hammered down the current equivalence hierarchy, including the operators. There was even a suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, but we finally decided that the paying attention to binding and exact IEEE754 equivalence was too advanced for most uses, so = was assigned to the most forgiving form of equality. Many other languages with an equivalence hierarchy have made a similar choice, so it shouldn't be too surprising. | 10-Nov 16:45 |
| 9793 | Geomol | I guess, the question is, whether chars should be more number-like or more string-like. In R2, chars are number-like except in maybe PARSE, where they are string-like: >> parse "a" [#"A"] == true even if: >> #"a" = #"A" == false In R3, chars are somewhere in between being number-like and string-like, as I see it. We can still do much calculations with chars, but not all: >> 2 * #"a" == 194 >> 2 ** #"a" ** Script error: ** does not allow char! for its exponent argument The last is possible in R2. If chars should be more string-like, then make them so, Carl! This is really confusing: >> "a" > "A" == false >> #"a" > #"A" == true | 10-Nov 16:45 |
| 9792 | BrianH | = isn't "normal equal", it's approximate equal. All four of the equivalences are "normal", for different circumstances. | 10-Nov 16:38 |
| 9791 | BrianH | Consistency between the behavior of = between characters and strings is really important. R3 is better than R2 in that regard. | 10-Nov 16:30 |
| 9790 | Oldes | >> (1 * #"a") = (1 * to integer! #"a") == true | 10-Nov 11:21 |
| 9789 | Oldes | I'm pretty sure the current behaviour is the better one.... and why something can be larger? >> to-integer #"a" == 97 >> to-integer #"A" == 65 | 10-Nov 11:20 |
| 9788 | Henrik | Already documented: http://curecode.org/rebol3/ticket.rsp?id=1497&cursor=13 | 10-Nov 9:25 |
| 9787 | Henrik | I don't necessarily agree. In fact, when there is already a case sensitive solution (==), this seems meaningful enough, if you want a fast and memory efficient case-insensitive comparison. | 10-Nov 9:22 |
| 9786 | Geomol | Like in R2, I guess. You could convert them to strings. And some functions, like PARSE, deal with it. I'm not 100% sure, it's the best way, but it's better than this, I think. | 10-Nov 9:20 |
| 9785 | Henrik | How would you otherwise compare single upper and lowercase chars, then? | 10-Nov 9:18 |
| 9784 | Geomol | Because chars can be used as numbers, this rule leads to strange things like: >> a: #"a" == #"a" >> b: #"A" == #"A" >> a = b == true >> (1 * a) = (1 * b) == false | 10-Nov 9:16 |
| 9783 | Geomol | But how can something both be equal and larger than something else (using normal equal)? Think about it! Look at strings: >> "a" = "A" == true >> "a" > "A" == false (I wouldn't go for this solution for chars though.) | 10-Nov 9:12 |
| 9782 | Oldes | >> #"a" == #"A"
== false >> #"a" == #"a" == true | 10-Nov 9:10 |
| 9781 | Oldes | no... | 10-Nov 9:10 |
| 9780 | Oldes | no... | 10-Nov 9:10 |
| 9779 | Geomol | In R3, upper- and lowercase chars are equal, which leads to: >> #"a" = #"A" == true >> #"a" > #"A" == true Isn't that a mistake? | 10-Nov 9:08 |
| 9778 | GrahamC | Yeah, he was in quality assurance and testing | 8-Nov 23:46 |
| 9777 | BrianH | Bo used to work for RT, afaik. | 8-Nov 21:35 |
| 9776 | GrahamC | Bo lives in Ukiah as well. | 8-Nov 21:27 |
| 9775 | eFishAnt | a quote from there ... http://www.efishantsea.com/devcon2004/bloopers.html | 8-Nov 16:06 |
| 9774 | eFishAnt | Bo did a talk at REBOL/Collaboration 2004 and is quoted in the notes. Oh yeah, here's his bio... http://www.efishantsea.com/devcon2004/bios.html | 8-Nov 16:02 |
| 9773 | Henrik | Found out. | 8-Nov 12:18 |
| 9772 | Henrik | Who is this person? | 8-Nov 12:15 |
| 9771 | Pekr | I just noticed Bohdan Lechnowsky saying following on Facebook: "I know for a fact that Carl was working on R3 this past weekend." Any insider info on that? | 8-Nov 10:10 |
| 9770 | Singy | Thanks Robert - that works fine - now :) Henrik was correct at the time, the server was having problems - it is what prompted my question. | 3-Nov 20:21 |
| 9769 | Robert | No server problems: http://www.saphirion.com/development/r3-gui/ | 3-Nov 16:46 |
| 9768 | Henrik | Singy, it should be on saphirion.com, but there are some server problems currently. | 3-Nov 7:59 |
| 9767 | Singy | Ladislav, how do we now access the R3 GUI and the REBOL core on which it runs? | 2-Nov 21:00 |
| 9766 | Claude | well................ carl where are you ????? | 2-Nov 13:42 |
| 9765 | Andreas | "no native CGI support in R3" True, although that "native" support is barely needed. `get-env` and `system/ports/input` are basically all you need. I am running several R3 CGIs which work just fine. | 1-Nov 14:53 |
| 9764 | Andreas | "weak and underpowered CALL.No /output or /wait parameter IIRC." I agree with the general notion (that CALL is weak, atm), but: /wait is there (albeit not working on Linux, IIRC). /output is missing indeed. But CALL is fully doable as extension or from within the hostkit. So if anyone really needs it, it's a matter of either developing it yourself or funding the development. (Feel free to contact me, if interested in the latter.) | 1-Nov 14:36 |
| 9763 | Ladislav | "Sorting & Unicode - althought we have Unicode strings available, sort is not adapted to that, and the question is, if it can be easily done ..." - this is not a disadvantage of R3, in this case R3 surely is better than R2 | 1-Nov 11:17 |
| 9762 | Henrik | it hasn't | 1-Nov 11:08 |
| 9761 | Pekr | Ladislav - as due to low public interest the GUI is not going to be published so often, I would like to ask, if some work on "nice skin" has already started? (I am referring to a blog post :-) | 1-Nov 10:58 |
| 9760 | Ladislav | - the development of the GUI is continuing, for every new version of the interpreter, the corresponding GUI version is available | 1-Nov 10:40 |
| 9759 | Ladislav | "there is still no official GUI for R3" - frankly, that is inaccurate. The GUI is "official" in the following senses: - Carl "delegated" the GUI development to our team - the GUI is the continuation of the Carl's version - the GUI is available for everyone - the documentation is available as well | 1-Nov 10:38 |
| 9758 | GrahamC | I thought Kaj was using R3 for cgi ?? | 1-Nov 9:05 |
| 9757 | Pekr | Other than that, R3 has the advantages Ladislav mentioned. So if you can live with some limitiations I named, you should be OK in using R3. | 1-Nov 9:01 |
| 9756 | Pekr | I would add following "negatives" (depends upon how you look into it): - no /libary extension and easy wrapping of DLLs. There was a bounty started to bring in kind of R2 DLL capabilities using extensions, Max was working on something, but did not deliver. Some ppl claim, that working with extensions is easy enough, much more powerfull, and that in fact R2 /library interface was weak in comparison in capabilities. - weak and underpowered CALL.No /output or /wait parameter IIRC. Carl said, that R2 C code to it was complex, and that the code is eventually awailable for volunteer to bring in to R3. The outcome is - CALL is limited in usage in comparison to what can be easily achieved in R2. - protocols. The only protocol IIRC was available was HTTP, done by Gabriele. It was HTTP 1.1 compatible, but due to some bug (?) it was downgraded to 1.0 version. No proxy support. Other protocols were done by some other ppl, I do remember Graham doing some work here. In regards to protocols, IIRC there was some work done by Kaj, who brought Curl networking extension to R3. - under Windows console is a bit more inconvenient in usage than in R2, we use native Windows console, yet we don't have full console support, so we can't replace the native R3 one by e.g. Console2 or some other version ... - DBAccess - forget R2 protocols available. The rescue is ODBC extension for R3 - CGI - no native CGI support in R3, though it should not be difficult to emulate - Sorting & Unicode - althought we have Unicode strings available, sort is not adapted to that, and the question is, if it can be easily done ... | 1-Nov 8:58 |
| 9755 | Henrik | Perhaps also of importance is that many bugs are already well-documented and are actively being discussed in Curecode with R3 rather than the simple non-discussed reports for RAMBO with R2. | 1-Nov 8:55 |
| 9754 | Pekr | Well done, Ladislav. | 1-Nov 8:44 |
| 9753 | Endo | Ashley: Good question, thank you. Ladislav: Thank you for the answer. "apart from GUI": there is still no official GUI for R3. You can use RMA's. | 1-Nov 8:43 |
| 9752 | Robert | - Much better extensions than R2. It's super simple to write an R3 extension. | 1-Nov 8:34 |
| 9751 | GrahamC | protocols are untested | 1-Nov 8:22 |
| 9750 | GrahamC | no easy access to libraries ... | 1-Nov 8:20 |
| 9749 | Ladislav | Also, less test failures than for R2 | 1-Nov 7:19 |
| 9748 | Ladislav | Other advantages: 556 more tests than for R2 (see testing and tools group) | 1-Nov 7:18 |
| 9747 | Ladislav | Here is my short list (I am sure I forgot to mention a lot of things other people may find important) Advantages of R3: - new datatypes -- map!, money!, percent!, closure!, module!, typeset!, command!, get-path!, - enhanced objects - enhanced errors - support for UNICODE strings - enhanced bitsets (support for UNICODE) - enhanced pairs - 64-bit integers - better conversions (to binary! and back) - enhanced PARSE -- new keywords added - enhanced MOLD -- improved MOLD/ALL - enhanced LOAD - some functions became natives -- native APPEND - more complete set of comparison functions -- EQUIV? added - much better RANDOM - enhanced loops (CONTINUE) - enhanced debugging capabilities (call stack) - enhanced protection (PROTECT) - improved GC - more open (the host-kit is open source) Disadvantages: - missing list! (the demand for the datatype was low) - missing hash! (for the majority of applications map! should be faster and more comfortable) - no adequate substitute for the [throw] function attribute exists yet - missing struct! (for substitute, see extensions) | 1-Nov 7:08 |
| 9746 | Ashley | On a separate note, I want to standardize on either R2 or R3 for work (no GUI or SDK required). What are the advantages of R3 compared to R2 at present, and what (apart from GUI and SDK) can R2 do that R3 can't? | 1-Nov 5:08 |
| 9745 | Ashley | How do you load a DLL in R3? In R2 I'd code: *lib: load/library %sqlite3.dll version: make routine! [return: [string!]] *lib "sqlite3_libversion" but the R3 'load native doesn't have a /library refinement any more. It also seems that routine! has been replaced with library! | 1-Nov 5:04 |
| 9744 | Ladislav | Regarding the http://issue.cc/r3/1893 The USE-RULE/NO-REBIND variant can serve as an example of a case, where "early binding to function context" would make the code more flexible. | 12-Oct 23:07 |
| 9743 | Ladislav | Well, APPEND PORT "^/" actually works. Just APPEND PORT NEWLINE does not | 12-Oct 23:01 |
| 9742 | BrianH | APPEND ? Why not WRITE ? Still, it shouldn't crash. | 12-Oct 15:48 |
| 9741 | Ladislav | (a crash report) | 12-Oct 15:47 |
| 9740 | Ladislav | http://issue.cc/r3/1894 | 12-Oct 15:46 |
| 9739 | BrianH | What about 5 or 6 byte overlong forms? | 12-Oct 14:57 |
| 9738 | BrianH | Change of subject: Has anyone sent mass emails in R3? I need to send some (legitimately, internally) from data that R3 processed. | 12-Oct 14:56 |
| 9737 | BrianH | Good - we can fix R2's version, but not easily fix R3's. | 12-Oct 14:51 |
| 9736 | Andreas | So, R3's invalid-utf? seems to flag overlong encodings in general. R2(/Forward)'s invalid-utf? only catches overlong forms for 2-byte sequences, but not for 3- or 4-byte sequences. | 12-Oct 14:12 |
| 9735 | Andreas | Same for the 4-byte overlong sequence #{f08080af}. R3 correctly detects it as wrong, R2 does not. | 12-Oct 14:11 |
| 9734 | Andreas | R2>> invalid-utf? #{e080af}
R2== none R3>> invalid-utf? #{e080af} R3== #{e080af} | 12-Oct 14:02 |
| 9733 | Andreas | #{e080af} is an overlong form for #"/", for example. | 12-Oct 14:02 |
| 9732 | Andreas | Ok. R2's invalid-utf? catches all 2-byte overlong forms, but not all 3 or 4-byte overlong forms. | 12-Oct 14:01 |
| 9731 | BrianH | Well, if it doesn't have a ticket yet it could use one. | 12-Oct 13:48 |
| 9730 | Andreas | The above is a bug in R3, in any case. | 12-Oct 13:47 |
| 9729 | Andreas | Mixed up R2 and R3 here. | 12-Oct 13:47 |
| 9728 | BrianH | I'm talking about the R3 version, which is a native that doesn't use PARSE. Do you think it's a related bug? | 12-Oct 13:46 |
| 9727 | Andreas | >> parse/all #{f0} reduce [charset [#{d0}]] == true | 12-Oct 13:45 |
| 9726 | Andreas | Which definitely is worth a ticket. | 12-Oct 13:45 |
| 9725 | Andreas | No, that's nothing to do with overlong forms, but with PARSE in combination with bitsets being broken. | 12-Oct 13:44 |
| 9724 | BrianH | Other overlong forms are not being screened for, but one form is? That would also be worth a ticket. | 12-Oct 13:42 |
| 9723 | Andreas | It is only in this particular case. | 12-Oct 13:40 |
| 9722 | BrianH | If it is returning anything other than none for an overlong form, it is screening for overlong forms. | 12-Oct 13:40 |
| 9721 | BrianH | INVALID-UTF? returns the series at the position of the first invalid sequence. If it doesn't flag it returns none. | 12-Oct 13:39 |
| 9720 | Andreas | Or at least, it behaves the same as in R2. | 12-Oct 13:38 |
| 9719 | BrianH | And we could use a ticket for the TRANSCODE bugs. | 12-Oct 13:38 |
| 9718 | Andreas | No, it doesn't. | 12-Oct 13:38 |
| 9717 | BrianH | So, on R3 INVALID-UTF? flags overlong encodings? Sorry I missed that. Better fix the R2/Forward version accordingly. | 12-Oct 13:36 |
| 9716 | Andreas | So for words, transcode is behaving strange. On the other hand, for strings ({"} is #{22}): >> transcode #{22c0ae22} == ["." #{}] | 12-Oct 13:12 |
| 9715 | Andreas | "The only function in R3 that operates that way is TRANSCODE, so as long as it doesn't choke on overlong combinations" #{c0ae} is an overlong encoding for #"." (#{2e}). >> invalid-utf? #{c0ae} == #{C0AE} >> transcode #{c0ae} == [® #{}] >> transcode #{2e} == [. #{}] | 12-Oct 13:11 |
| 9714 | Henrik | ladislav, yes, saw it just now. :-) | 11-Oct 11:26 |
| 9713 | Ladislav | remove-each [value skip] my-block [...] | 11-Oct 11:26 |
| 9712 | Henrik | nevermind. please ignore request. | 11-Oct 11:26 |
| 9711 | Henrik | would it not be practical if REMOVE-EACH could /SKIP ? | 11-Oct 11:24 |
| 9710 | Ladislav | Supporting comment added. | 10-Oct 21:42 |
| 9709 | BrianH | Initial version of the ticket made: http://issue.cc/r3/1893 | 10-Oct 16:38 |
| 9708 | BrianH | Yup. And BODY-OF returning an unbound copy prevents code like this: print get second body-of :a PROTECT/hide doesn't affect existing bindings, so you need to be careful about leaking those too. | 10-Oct 0:22 |
| 9707 | Ladislav | So, for the case of BIND [...] function the main difference is, that it cannot be done regardless of whether the function is running or not, which can be considered a security measure, then. | 10-Oct 0:18 |
| 9706 | Ladislav | Anything | 10-Oct 0:12 |
| 9705 | BrianH | I'll write it up, if it's OK to copy some of your arguments from above into the ticket. | 10-Oct 0:11 |
| 9704 | Ladislav | Unfortunately, the whole issue may be quite long to present completely | 10-Oct 0:10 |
| 9703 | BrianH | Especially ones where the bound words are leaked intentionally to provide access to the context. It sounds worthy of a wish ticket in CureCode. | 10-Oct 0:09 |
| 9702 | Ladislav | Yes, it only prevents some meaningful uses | 10-Oct 0:07 |
| 9701 | BrianH | "then the ban on BIND to a function-context-bound word when the function isn't running has no security benefit" :) | 10-Oct 0:02 |
| 9700 | BrianH | True, which is why I was convinced by that particular argument :) | 10-Oct 0:01 |
| 9699 | Ladislav | OK, but nothing of that kind applies to the case of BIND [...] 'some-variable | 10-Oct 0:00 |
| 9698 | BrianH | I had to go though the mezzanine code pretty carefully to consider what happens when functions are passed as arguments to the mezzanine functions. Some functions like REPLACE and ARRAY were modified to take advantage of that trick pretty nicely. | 9-Oct 23:50 |
| 9697 | BrianH | a func [] [print get bind 'stuff :a] | 9-Oct 23:47 |
| 9696 | Ladislav | aha, sorry, now I see. | 9-Oct 23:47 |
| 9695 | BrianH | No, you added a : there. The function is being passed to a as an argument. | 9-Oct 23:46 |
| 9694 | Ladislav | Do I understand correctly, that this is what you propose as demonstrating the reason for the functions not being accepted by BIND? a: func [] [do something to get access to hidden-stuff] | 9-Oct 23:45 |
| 9693 | BrianH | So, come up with some exploit code (that doesn't use STACK because we're assuming SECURE 'debug works). This is a real problem. | 9-Oct 23:45 |
| 9692 | BrianH | The 'stuff word isn't hidden, but it isn't leaked while the function is running. That means that the exploit code only has access to the :a function value. | 9-Oct 23:44 |
| 9691 | Ladislav | So, once again, your example demonstrating the existence of the (purported and nonexistent) reason failed. | 9-Oct 23:43 |
| 9690 | BrianH | a func [] [do something to get access to hidden-stuff] The function a doesn't exclude functions from its arguments and it refers to its argument with a word rather than a get-word, so it can be tricked into running code while it is running. That means its context is valid while the exploit code is running. | 9-Oct 23:43 |
| 9689 | Ladislav | Why it fails: because, even knowing the bound version of the 'stuff variable does not help me to get the HIDDEN-STUFF, so, the purported reason does not exist | 9-Oct 23:41 |
| 9688 | Ladislav | Yes, OK. So, now, let me cite: "The reason for this is so that functions can prevent access to their context from leaking to code *that the function calls* that could be exploited while the function is running." - don't you see, that your purported reason fails? | 9-Oct 23:39 |
| 9687 | BrianH | Or rather it's copied to system/contexts/user/a, but the point remains the same. | 9-Oct 23:38 |
| 9686 | BrianH | In those circumstances a reference to :a is copied to lib/a, but there is no reference to the module saved except the PROTECT/hide reference to hidden-stuff in the block of :a. | 9-Oct 23:37 |
| 9685 | BrianH | Right. Let me make that more explicit: import module [] [hidden hidden-stuff: "something you want" export a: func [code /stuff] [stuff: hidden-stuff code]] | 9-Oct 23:36 |
| 9684 | Ladislav | Does not matter, it is just an assumption, I am just asking whether you don't mind me making it. | 9-Oct 23:35 |
| 9683 | BrianH | It's just a placeholder. If you have a PROTECT/hide exploit, that's interesting too but off-topic. | 9-Oct 23:34 |
| 9682 | Ladislav | So, do I assume correctly, that I cannot examine the BLAH module to get the HIDDEN-STUFF value? | 9-Oct 23:34 |
| 9681 | Ladislav | OK, fine, an example that looks meaningful to you. | 9-Oct 23:33 |
| 9680 | BrianH | blah: module [] [hidden hidden-stuff: "something you want" a: func [code /stuff] [stuff: hidden-stuff code]] blah/a func [] [do something to get access to hidden-stuff] | 9-Oct 23:32 |
| 9679 | Ladislav | As said, using the properties of REBOL functions, I can easily prove you wrong in any case you invent. | 9-Oct 23:31 |
| 9678 | Ladislav | Any example? | 9-Oct 23:29 |
| 9677 | BrianH | If getting access to 'stuff is the only way to get access to what it refers to, how do you get access to 'stuff if all you have is :a ? | 9-Oct 23:28 |
| 9676 | Ladislav | It is you failing to provide a reason, and, I am actually able to prove there is none. | 9-Oct 23:28 |
| 9675 | Ladislav | I cannot, it is up to you to find *any* meaningful example, which I am maintaining is impossible. | 9-Oct 23:27 |
| 9674 | BrianH | Ignore the particular literal value there, and substitute it with something that outside code can't otherwise get access to, like the results of a call to a function that is referred to by a PROTECT/hide variable. | 9-Oct 23:26 |
| 9673 | Ladislav | Your trouble is, that you do not see, that the triviality of your problem matters. | 9-Oct 23:26 |
| 9672 | Ladislav | As said, I do not have to. The string is already there for me to read. | 9-Oct 23:25 |
| 9671 | BrianH | No, seriously, I meant it. How do you do this without BIND 'stuff :a ? | 9-Oct 23:24 |
| 9670 | Ladislav | As said, problem solved. You need something nontrivial to throw at me. | 9-Oct 23:23 |
| 9669 | BrianH | That was just a placeholder. The stuff variable could be the results of a prompt to the user for their password, or of a native function that decrypts something. One problem at a time. | 9-Oct 23:22 |
| 9668 | BrianH | This is the reason for that particular restriction. If there's a workaround that we don't yet know about, let us know so we can plug it. | 9-Oct 23:21 |
| 9667 | Ladislav | your example is too trivial. I get the access to the "something secret..." too easily, jut by examining the function body. Don't you have anything more complicated? | 9-Oct 23:21 |
| 9666 | BrianH | a: func [code /stuff] [stuff: "something secret, not a literal string" code] With just a reference to :a, bind 'stuff to the function context. The function could be running or not when you get access to the bound word 'stuff. The exploit code can then be passed to the function in its code argument, which would then have access to the contents of 'stuff because the function is running. | 9-Oct 23:19 |
| 9665 | Ladislav | But, the reasons for disallowing the functions as the BIND arguments have actually a similar flaw. | 9-Oct 23:18 |
| 9664 | Ladislav | "No..." - still unrelated | 9-Oct 23:15 |
| 9663 | BrianH | No, the above is the exact reason for: >> not find second types-of :bind function! == true | 9-Oct 23:14 |
| 9662 | Ladislav | To remind you, I am and was always referring to this: >> f: func [a b] ['a] >> bind [b] f 1 2 ** Script error: none word is not bound to a context ** Where: bind ** Near: bind [b] f 1 2 The above is unrelated | 9-Oct 23:13 |
| 9661 | BrianH | The "But the ban on BIND to the function! value *itself*..." statement refers to this:
>> not find second types-of :bind function!
== true The BIND function doesn't accept function! values for its context argument. The reason for this is so that functions can prevent access to their context from leaking to code *that the function calls* that could be exploited while the function is running. All the function has to do is not leak bound words, and it's safe. If that doesn't work, please show how. | 9-Oct 23:10 |
| 9660 | Ladislav | And, regarding to your "password problem", you are still trying to impose unrelated conditions. As is obvious, nobody can read a password from a function not referring to it when the function is not running. Thus, you cannot purport, that for the security of said password it is necessary to forbid something when the function is not running. It is not. | 9-Oct 23:09 |
| 9659 | BrianH | And no, using STACK still doesn't count because it's known, and blocked if SECURE works. | 9-Oct 23:05 |
| 9658 | Ladislav | Why are you stating disprovable statements, and when I call them as such, you invent completely unrelated statements requiring me to prove them? | 9-Oct 23:04 |
| 9657 | BrianH | OK, get access to a function context with just a reference to the function itself. It doesn't matter if you run the function, because the function doesn't leak any bound words. | 9-Oct 23:03 |
| 9656 | Ladislav | "But the ban on BIND to the function! value *itself* still has value, because it would defeat the efforts to prevent any bound words from leaking out of the function from helping. " - another disprovable statement | 9-Oct 23:02 |
| 9655 | Ladislav | I do have a proof, which disproves your exact citation | 9-Oct 23:01 |
| 9654 | BrianH | OK, so you don't have a solution to that problem (darn, I was looking forward to that), but you have a proposed proof that it doesn't matter because you can't exploit it until the function is running. And since the BIND restriction when the function isn't running doesn't apply when the function *is* running later, even when applied to the same word, then the ban on BIND to a function-context-bound word when the function isn't running has no security benefit. But the ban on BIND to the function! value *itself* still has value, because it would defeat the efforts to prevent any bound words from leaking out of the function from helping. Otherwise it would be unsafe to let untrusted code call safe functions because they would need to have a reference to the function in order to call it. | 9-Oct 23:00 |
| 9653 | Ladislav | Sorry for using the power of logic, but I just am unable to see illogical statements as "good reasons". | 9-Oct 22:59 |
| 9652 | Ladislav | Proof: 1) Due to the way how the function contexts are implemented in R3, the word 'b in F's context does not refer to a password when F is not running. 2) Because of that, I either cannot read the password at all, or have to be able to read it somehow, which is possible *only* when the function is running. (oherwise, there is no danger of me reading the password as is well known) 3) do I have to continue? | 9-Oct 22:45 |
| 9651 | Ladislav | Sure, still trivial | 9-Oct 22:40 |
| 9650 | BrianH | Just with access to a reference to the function itself, and and a word bound to its context. | 9-Oct 22:40 |
| 9649 | Ladislav | Yes, it is easy | 9-Oct 22:40 |
| 9648 | BrianH | OK, prove it without having access to the original body code (a separate issue), and while the function isn't running (another separate issue). | 9-Oct 22:39 |
| 9647 | Ladislav | Do you want me to? | 9-Oct 22:39 |
| 9646 | Ladislav | That can be easily disproved. | 9-Oct 22:38 |
| 9645 | Ladislav | OK, I will cite you exactly: "Sure it is, in some cases. What if 'a is harmless, but 'b refers to a password? If you can only CHANGE, not BIND, then leaking a word is only as dangerous as leaking what that word refers to. If you can BIND using that word as a context, you can get access to *every* value referred to by that context, not just the one. So it's still potentially a problem to leak a single word (depending on what gets assigned to that one word), but not as bad a problem as it could be. | 9-Oct 22:37 |
| 9644 | BrianH | My last message had the reasons. What you are talking about are the means. | 9-Oct 22:36 |
| 9643 | Ladislav | Thus, the purported reason is not a reason at all, surely not "good". | 9-Oct 22:36 |
| 9642 | Ladislav | Above you mentioned, that the reson is this: - if I had access to a 'var-a variable bound to the F's context, and if I were able to do "some harm" having another variable 'var-b bound to the F's context, then that is a good reason why to cripple BIND, to not give me the access to the 'var-b bound to the F's context as well when the function is not running. As stated, I can disprove that as a reason. | 9-Oct 22:35 |
| 9641 | BrianH | We are trying to prevent functions from being modified from the outside without changing the function (SAME? test), and to allow functions to work on information that we want to keep hidden from other code, such as when a variable has an unencrypted password in it or other sensitive information. Or we could just give up on being able to run untrusted code because it's futile, as you are requesting. | 9-Oct 22:35 |
| 9640 | Ladislav | ...have good reasons | 9-Oct 22:30 |
| 9639 | Ladislav | "What you are requesting is something that we are trying to prohibit, and we have good reasons for doing so. " - by the above, I just proved, that you do not | 9-Oct 22:30 |
| 9638 | BrianH | We can plug one hole at a time. What you are requesting is something that we are trying to prohibit, and we have good reasons for doing so. If there are also other means of doing it, we can address those issues later. One issue at a time. | 9-Oct 22:29 |
| 9637 | Ladislav | Yes, but my intent was to prove, that the BIND crippling is unreasonable, which is provable. | 9-Oct 22:27 |
| 9636 | BrianH | Ah, but that is the only question I was asking. | 9-Oct 22:26 |
| 9635 | Ladislav | Yes, but I never offered the answer to your question. | 9-Oct 22:25 |
| 9634 | BrianH | I am asking something really specific (see my last message). | 9-Oct 22:25 |
| 9633 | Ladislav | (Even though the BIND function is "crippled*, but, as proven by the above statement, unreasonably so.) | 9-Oct 22:24 |
| 9632 | Ladislav | Once again, the assumptions are: - I have a word 'var-a bound to the F's context - It is true, that *if* I had a word 'var-b bound to the F's context, then I would be able to do "some harm" Provided that these conditions are met, then I am able to do the harm. | 9-Oct 22:23 |
| 9631 | BrianH | Let's ignore the function context aspect of it all, and simplify the problem. If you have a word bound to a context, and want to get access to another word bound to the same context, and don't have access to the BIND or IN functions at all, how would you do it? | 9-Oct 22:20 |
| 9630 | Ladislav | (I may have written it incorrectly, then, since that is not what I intended to write) | 9-Oct 22:19 |
| 9629 | Ladislav | Did I write that? | 9-Oct 22:18 |
| 9628 | Ladislav | Sorry? | 9-Oct 22:18 |
| 9627 | BrianH | The above statement requires either access to a word of the same spelling bound to the context. I'm talking about accessing a different word. | 9-Oct 22:16 |
| 9626 | Ladislav | Not much of a trick is needed. The above statement (when proven, which is easy), proves, that the disabling of BIND for non-running function words is not a security measure. | 9-Oct 22:11 |
| 9625 | BrianH | Oh, that's what you meant. I was asking specifically about the particular question I asked. It sounded like you were saying you had a way to do a BIND without BIND. If so, that would be an interesting trick, but also a security hole. I'm more interested in the trick though, if it exists. | 9-Oct 22:08 |
| 9624 | Ladislav | "I'm curious: How can you get a word 'b bound to a function context, when the function is not running, you don't have access to the original function body, and all you have is a word 'a bound to that same context? No command or extension tricks either - they're already assumed to be unsafe." - I offer you this statement, which I *can* prove in a reasonable sense: - I assume, that F is a function having a context with more than one variable (Otherwise, there is nothing to prove, is there?) -, so, for the simplification, let's assume, that there are variables 'var-a and 'var-b in F's context, such that: - the Attacker has already access to the variable 'var-a bound to the F's context - , but he does not have the access to the variable 'var-b bound to the F's context yet - now, let's assume, that having access to the variable 'var-b in the F's context he would be able to "do some harm" (whatever that "harm" is) Provided, that the above conditions are met, the Attacker is already able to do the harm even not having the variable 'var-b bound to the F's context available yet. Do I have even to prove the statement? | 9-Oct 21:23 |
| 9623 | BrianH | Actually, I'd be really interested if you figure out how to use STACK to hack a function that isn't running - that would be a heck of a trick. | 9-Oct 19:21 |
| 9622 | BrianH | If it's the STACK function or something else that requires debug privileges to run, document it and move on. We already know STACK can be insecure, just not all of the tricks for doing so. | 9-Oct 18:56 |
| 9621 | BrianH | If there is a trick that doesn't require access to a block of code that already has a bound 'b in it, or that provides access to the bound body of a function without saving a reference to the body before the function is made, this is information we need to know to make R3 secure. | 9-Oct 18:54 |
| 9620 | BrianH | I'm curious: How can you get a word 'b bound to a function context, when the function is not running, you don't have access to the original function body, and all you have is a word 'a bound to that same context? No command or extension tricks either - they're already assumed to be unsafe. | 9-Oct 18:51 |
| 9619 | Ladislav | What it actually does, is that it disables to write some, otherwise clean, code. | 9-Oct 5:28 |
| 9618 | Ladislav | It surely is not a safety measure in any reasonable meaning, it is just an annoyance. | 9-Oct 5:26 |
| 9617 | Ladislav | But, if you do want to "play dirty", then having 'a is completely sufficient | 9-Oct 5:24 |
| 9616 | Ladislav | I am still sure, that disabling BIND in such cases is totally useless. (besides, when the function is not running, you cannot obtain the value of 'b even if you obtained 'b) | 9-Oct 5:22 |
| 9615 | Ladislav | (only in trivial cases it may be a problem) | 9-Oct 5:17 |
| 9614 | Ladislav | "What if 'a is harmless, but 'b refers to a password?" - you are most probably out of luck, leaking 'a means 'b is obtainable as well | 9-Oct 5:16 |
| 9613 | BrianH | You still have to be careful while the function is running though. | 9-Oct 0:08 |
| 9612 | BrianH | (Sorry, internet outage) Sure it is, in some cases. What if 'a is harmless, but 'b refers to a password? If you can only CHANGE, not BIND, then leaking a word is only as dangerous as leaking what that word refers to. If you can BIND using that word as a context, you can get access to *every* value referred to by that context, not just the one. So it's still potentially a problem to leak a single word (depending on what gets assigned to that one word), but not as bad a problem as it could be. | 9-Oct 0:07 |
| 9611 | Ladislav | As long as you "Leak out" one word, you actually leak out the whole context, just not for the people who don't want to use "dirty tricks" | 8-Oct 23:42 |
| 9610 | Ladislav | That is only "false safety", since it is circumventable | 8-Oct 23:33 |
| 9609 | Ladislav | yes, but that is not a safety measure. | 8-Oct 23:33 |
| 9608 | BrianH | >> head change [1] 'a
== [a]
>> head change [1] #"a"
== [#"a"] With BIND, you can leak the 'a word and get access to the 'b word from that same context. You can't do that with CHANGE. | 8-Oct 23:32 |
| 9607 | Ladislav | Binding just replaces all the words it "binds" | 8-Oct 23:31 |
| 9606 | Ladislav | And what else binding is in this case? | 8-Oct 23:30 |
| 9605 | BrianH | That isn't binding, that is changing to a word that is already bound. | 8-Oct 23:29 |
| 9604 | Ladislav | or, having the access to the body, you can do other tricks | 8-Oct 23:29 |
| 9603 | Ladislav | But, that is wrong, since when you let the word out, you can bind, just not using the BIND function (you need to use CHANGE for that) | 8-Oct 23:27 |
| 9602 | Ladislav | (since it does not enhance security in any way) | 8-Oct 23:25 |
| 9601 | BrianH | >> bind 'a do func [/a] ['a]
** Script error: a is not in the specified context
** Where: bind
** Near: bind 'a do func [/a] ['a] Well, then you don't have to be as careful with letting bound function words leak I guess. | 8-Oct 23:25 |
| 9600 | Ladislav | That is what I call "annoying" | 8-Oct 23:22 |
| 9599 | Ladislav | "But you can already BIND to a word bound to a function context." - actually, I cannot, if the function isn't already running (in that case BIND refuses to do that) | 8-Oct 23:22 |