| # | User | Message | Date |
| 5294 | Kaj | That explains why your measurement is pretty much the same as on my old CPU | Today 16:50 |
| 5293 | Kaj | But stupid Windows measures wall-clock time instead of processor time | Today 16:48 |
| 5292 | Kaj | http://en.allexperts.com/q/C-1040/time-milliseconds-Windows.htm | Today 16:48 |
| 5291 | Kaj | It's 1000: | Today 16:48 |
| 5290 | Kaj | 1000 or 10'000 really | Today 16:36 |
| 5289 | Kaj | Performancewise, 100 or 1000 seem most likely | Today 16:35 |
| 5288 | Dockimbel | Possible. | Today 16:35 |
| 5287 | Kaj | Sounds like that could be 50 in the US | Today 16:33 |
| 5286 | Dockimbel | IIRC, it should be 60 for Windows, but I'm not certain this is valid for all Windows versions. | Today 16:33 |
| 5285 | Kaj | Judging by your screenshot, it's different for Windows | Today 16:24 |
| 5284 | Kaj | ; CLOCKS_PER_SEC value for Syllable, Linux (XSI-conformant systems) ; TODO: check for other systems #define clocks-per-second 1000'000 | Today 16:23 |
| 5283 | Kaj | Fixed, thanks | Today 16:19 |
| 5282 | Dockimbel | Kaj: I've just pushed a fix for the floats exceptions and regressions. Mandelbrot is running fine again now. Let me know if the issues are fixed for you too. | Today 15:51 |
| 5281 | Kaj | The new "developing" branch is not compatible with Red/System 0.2.4 but is needed to use WebKit | Today 15:16 |
| 5280 | Kaj | http://red.esperconsultancy.nl/Red-C-library/timeline | Today 15:14 |
| 5279 | Kaj | I split the C library binding in two branches so that users of the Red release can keep using the main (trunk) branch: | Today 15:14 |
| 5278 | Pekr | the library is clearly a junk imo ... e.g. two consecutive calls to the same function do crash the app, etc. | Today 13:39 |
| 5277 | Pekr | yes, I confused it - ti came from R2, where I put char as a return value, and then to-integer ... I develop in in R2, Red/System, World, to see if eventual crashes are environment specific, or library specific | Today 13:39 |
| 5276 | Dockimbel | Pekr: it should be [as logic! _func-name], while setting [return: [byte!]] in _func-name definition. | Today 13:32 |
| 5275 | Kaj | It seems that Petr's library puts garbage in the high bytes if it returns 1 or a high integer | Today 13:29 |
| 5274 | Dockimbel | Kaj: the same way as you get a low integer. :) The signed representation is just a convention, the actual data remains the same, signed or unsigned. | Today 13:28 |
| 5273 | Dockimbel | Pekr: yes, that's an option. | Today 13:27 |
| 5272 | Pekr | I will look into #define ... | Today 13:27 |
| 5271 | Pekr | aha ... I would probably use something like _func-name ... and func-name: [as logic! as byte! _func-name] | Today 13:26 |
| 5270 | Kaj | Oh, right, the other way around. But how do you get a high integer from a library, then? | Today 13:25 |
| 5269 | Dockimbel | #define | Today 13:25 |
| 5268 | Pekr | macro? | Today 13:25 |
| 5267 | Dockimbel | No! But you can use a macro to avoid making a function wrapper. | Today 13:25 |
| 5266 | Pekr | or: return: as logic! as integer! [byte!], so that I would get true/false directly :-) | Today 13:24 |
| 5265 | Pekr | I mean, so I could write: return: as integer! [byte!] | Today 13:24 |
| 5264 | Dockimbel | Integer! _is_ signed in Red/System, byte! is not. | Today 13:23 |
| 5263 | Pekr | would it be possible to cast import values directly in import clauses, to prevent the need to write another wrapping functions? call me lazy :-) | Today 13:23 |
| 5262 | Kaj | It's very nice that Red/System has a first class logic! but external code doesn't know that | Today 13:23 |
| 5261 | Pekr | OK, that's clear at least now ... | Today 13:22 |
| 5260 | Kaj | The "other standard" for true is -1, but there are no signed integers in red/System, so that's where you get the high value from | Today 13:22 |
| 5259 | Dockimbel | Right, we extended the import interface to allow logic!, the spec doc seems to lag behind on that feature, it needs to be updated (with a note about 1/0 requirement in such case). | Today 13:22 |
| 5258 | Kaj | But you have to be sure that the library defines it as 0 or 1. There is no standard for it in C, but that's what Red uses | Today 13:20 |
| 5257 | Dockimbel | Logic! is stored as an integer (so 32-bit). The specification document is not supposed to describe the implementation (that's why I try to put implementation-specific details in special notes). Logic! uses 1/0 internally to represent true/false values, so if the imported function is not conforming to that convention, type casting to logic! won't work and a manual test would then be required. | Today 13:20 |
| 5256 | Kaj | gtk-set-window-resizable: "gtk_window_set_resizable" [ ; Set window resizability. window [gtk-window!] resizable? [logic!] ] | Today 13:19 |
| 5255 | Kaj | I do use logic! in #import: | Today 13:19 |
| 5254 | PeterWood | From the spec Red/System does not support the use of the logic! datatype in #import - http://static.red-lang.org/red-system-specs.html#section-14.1 The spec is also silent about how a the logic! field is actually stored. I'd guess a byte! but I'd probably be wrong. By the way no need to cast byte! to integer!, just test for #"^(00)" or #"^(01)". | Today 13:09 |
| 5253 | Pekr | One question towards library wrapping and type casting. One DLL function is defined as: typedef bool (WINAPI *LSN_OPENCARD)(void);//open led card When I defined the return type of wrapper funciton as LOGIC!, it was always true. When I defined it as an integer, it was either 1, or some really high integer number. So i took Cyphre's advice towards R2's interface, and in R2 I used CHAR, and in Red/System, I used BYTE! type. Pity construct of a type return: "as integer! [byte!]" is not allowed, but at least I now get correct result - 0, or 1, in my print statement, where I do: print [as integer! led-open-card lf] So my question is - why using Red/System's LOGIC! did not work? Is C level BOOL a clearly defined type, or can it be defined in various ways, so I can't say, that I can automatically use LOGIC! = BOOL logic, when wrapping stuff? | Today 12:38 |
| 5252 | PeterWood | This code will cause an access violation as clock in libc returns an integer not a pointer to an integer. pi: declare pointer! [integer!] #import [ LIBC-FILE cdecl [ read-cpu-clock: "clock" [ return: [pointer! [integer!]] ] ] ] pi: read-cpu-clock pi/value | Today 12:15 |
| 5251 | PeterWood | The runtime errors that I got were correct - in the sense that the compiler and run-time acted correctly. | Today 12:13 |
| 5250 | PeterWood | Yes my reponse was mainly to Petr as it may be of help to him. | Today 12:12 |
| 5249 | Kaj | You probably mainly meant that as a response to Petr | Today 11:35 |
| 5248 | Kaj | Peter, yes, but this is the same Mandelbrot that worked with the 0.2.4 release | Today 11:33 |
| 5247 | Kaj | Mine is on Linux | Today 11:32 |
| 5246 | Dockimbel | Mandelbrot: it produces an error here too, but not the same one (testing on Win7): *** Runtime Error 11: float stack check | Today 9:39 |
| 5245 | Dockimbel | FP exceptions: will look into it. Peter: can you send me an example code of your use case raising a FP exception? | Today 9:31 |
| 5244 | Dockimbel | Kaj: `show-fpu-state` was renamed to `show-fpu-info` yesterday. I forgot to mention it here. | Today 9:28 |
| 5243 | PeterWood | I've found the easiest way to raise that runtime error is to accidently treat an integer as a pointer. | Today 8:34 |
| 5242 | Pekr | I got that error too. I thought it is related to my weak attempts to wrap my led library (which still can be the case), as I saw the error for the first time yesterday ... | Today 8:24 |
| 5241 | Kaj | At least the browser works again on my WebKit version | Today 1:01 |
| 5240 | Kaj | *** Runtime Error 1: access violation *** at: 08049FACh | Today 0:50 |
| 5239 | Kaj | I've added your FPU code to the C binding because all floating point code now generates an exception, but now the Mandelbrot doesn't work anymore: | Today 0:50 |
| 5238 | Kaj | I'm compiling with -g but show-fpu-state is not available | Today 0:44 |
| 5237 | Kaj | Responded | Tue 21:09 |
| 5236 | Dockimbel | Kaj: see my comment wrt `__libc_start_main` at https://github.com/dockimbel/Red/issues/129#issuecomment-4082942 | Tue 19:27 |
| 5235 | Dockimbel | Kaj: where can I find the source code for __libc_start_main using Syllable online sources browser? | Tue 18:16 |
| 5234 | Dockimbel | Kaj: I have enabled underflow and overflow exceptions in x87 by default for Red/System. This will help us write more reliable code. We'll be able to optionally disable all FPU exceptions once we get support for INF and NaN. So the init code for C lib is now: #if target = 'IA-32 [ system/fpu/mask/underflow: on system/fpu/mask/overflow: on system/fpu/mask/zero-divide: on system/fpu/mask/invalid-op: on system/fpu/update ] or in shorter, but less readable form: #if target = 'IA-32 [ system/fpu/control-word: 033Fh system/fpu/update ] | Tue 12:54 |
| 5233 | Dockimbel | Float issues for IA-32 fixed. Need to also fix them for ARM (tomorrow). | Tue 0:21 |
| 5232 | Kaj | Unfortunately, if I put that code in the C binding now, there will be no compatible Red/System release, so I'll put it in the WebKit binding first | Mon 23:43 |
| 5231 | Dockimbel | Ok, it's just the new tests added by Peter which are triggering a runtime error (related to issue #205). So, playing with your browser code should work fine. | Mon 20:28 |
| 5230 | Kaj | OK, I will wait a bit | Mon 20:17 |
| 5229 | Dockimbel | BTW, I'm currently tracking some regressions in floats support, the last commit doesn't pass all the float tests. | Mon 20:17 |
| 5228 | Dockimbel | Right, it should be put before _any_ call to floating point code. | Mon 20:15 |
| 5227 | Kaj | Then it should indeed be in the C library binding, but probably in the main file, because I will also move a few other functions there that use floating point | Mon 20:14 |
| 5226 | Dockimbel | It seems to be standard way for C floating point handling. | Mon 20:11 |
| 5225 | Kaj | OK. Is it a standard that they should be disabled, or is WebKit just sloppy? | Mon 20:11 |
| 5224 | Dockimbel | No, the masks are disabling the exceptions, so they need to be turned on to avoid raising them. I guess I should have made it more intuitive, instead of just mapping the low-level bits as-is... | Mon 20:10 |
| 5223 | Kaj | Very nice, thanks! I suppose they should be turned OFF instead of ON? | Mon 20:07 |
| 5222 | Dockimbel | ...turn <on>... | Mon 19:15 |
| 5221 | Dockimbel | BTW, I guess I should also turn underflow and overflow exceptions for Red/System by default... | Mon 19:15 |
| 5220 | Dockimbel | Kaj: in order to get the LazySunday browser working, you need to add at the beginning of %math.reds: #if target = 'IA-32 [ system/fpu/mask/zero-divide: on system/fpu/mask/invalid-op: on system/fpu/update ] This will disable the exceptions used by Red/System to raise runtime errors on float operations. All x87 exceptions should be disabled when calling C functions. | Mon 19:11 |
| 5219 | Dockimbel | Added support for `system/fpu/*` read/write properties. This allow controling the FPU at very low-level at runtime.
When compiling in debug mode, `show-fpu-state` function is available to print the current FPU properties: `show-fpu-state` When called on IA-32, it would output:: FPU type: x87 - control word: 0000037A - rounding : nearest - precision : double extended (80-bit) - raise exceptions for: - precision : no - underflow : no - overflow : no - zero-divide: yes - denormal : no - invalid-op : yes See %red-system/runtime/system.reds for definitions and %debug.reds for a usage example. | Mon 19:08 |
| 5218 | Oldes | Here is the fix in the pull request: https://github.com/dockimbel/Red/pull/206/files | Mon 14:03 |
| 5217 | PeterWood | Yes it is possible to test for a warining message. assert-msg? simply does a find on the compiler output for the supplied string. | Mon 13:50 |
| 5216 | Oldes | Forget it- it is, I was modifying the autogenerated file. | Mon 13:36 |
| 5215 | Oldes | enum-redec-10 must be changed | Mon 13:31 |
| 5214 | Oldes | Is it possible to test warning message? | Mon 13:31 |
| 5213 | PeterWood | In that case isn't a local to the function? | Mon 13:24 |
| 5212 | Oldes | And so what is expected behaviour for: #enum test! [a b] f: func[a [c-string]][] | Mon 13:21 |
| 5211 | PeterWood | I've added the example of the proposed change to enum-test.reds (Enum-11). | Mon 13:01 |
| 5210 | Dockimbel | Oldes: I agree with your fix, the locally defined value should prevail over the enumeration value. | Mon 12:28 |
| 5209 | Oldes | I don't have time to check it now more deeply... maybe in the evening. | Mon 11:04 |
| 5208 | Oldes | the problem is, that now it throws this error if C is used in enum: *** Compilation Error: type mismatch on setting path: char/1 *** expected: [byte!] *** found: [integer!] *** in file: %runtime/utils.reds *** in function: prin-byte *** at line: 29 *** near: [ char/1: c prin char c | Mon 11:04 |
| 5207 | Pekr | warning's good in such a case imo, or your app will most probably behave incorrectly in the runtime anyway, no? | Mon 10:32 |
| 5206 | Endo | I think this is the correct behaviour, more compatible with REBOL as well. I'm not sure about giving a warning if a local var. clashes with a global one (just for enums may be?) | Mon 10:14 |
| 5205 | Oldes | f: func[][ b: 3 ] ;throws error as before | Mon 9:57 |
| 5204 | Oldes | I've modified the behaviour as you want, but we should wait what Doc will think about it. Now it works like: #enum test! [a b] f: func[/local b][ b: 3 ?? b ] f ;will print 3, not 1 | Mon 9:56 |
| 5203 | Oldes | You are right. | Mon 8:57 |
| 5202 | Endo | oops sorry, I wrote "b = 0" should be "b: 0" | Mon 8:53 |
| 5201 | Endo | its another issue I think, in my example there is no c. Example 1: #enum test [a b] b = 0 ;<--- global, redeclaration error, which is correct. Example 2: b = 0 ;global f: func [/local b] [] ;<--- no error, correct Example 3: #enum test [a b] f: func [/local b] [] ;<--- redeclaration error, incorrect! local b should not be clashed with enumarated-global b | Mon 8:52 |
| 5200 | Oldes | first i should use c: 0, and it compiles, so it's related to enums. | Mon 8:50 |
| 5199 | Oldes | (ech my error) | Mon 8:48 |
| 5198 | Oldes | if I compile just:
c = 0;
I get: *** Compilation Error: local variable c used before being initialized! it's not bug related to enumerations. | Mon 8:47 |
| 5197 | Endo | which could be problem in a big source. "...prevent passing..." catch in compile time would be nice for sure. | Mon 8:46 |
| 5196 | Endo | You are right.
The problem above, enumrated value clashes with a local variable in a function. #enum test! [a b] ;... f: func [a [integer!] /local b] [] ;<---- compile error, "redeclaration of b" | Mon 8:45 |
| 5195 | Oldes | I was also thinking about value test to prevent passing for example value 10 as a method in the MagickRemapImage, as it accepts only values 0, 1and 2. This is not implemented yet. | Mon 8:43 |
| 5194 | Oldes | Such an enumeration you can use in the import like: #import [ "CORE_RL_wand_.dll" cdecl [ MagickRemapImage: "MagickRemapImage" [ ;== Replaces the colors of an image with the closest color from a reference image ;-- MagickBooleanType MagickRemapImage(MagickWand *wand,const MagickWand *remap_wand,const DitherMethod method) wand [MagickWand!] ;the magick wand. remap_wand [MagickWand!] method [DitherMethod!] ;choose from these dither methods: NoDitherMethod, RiemersmaDitherMethod, or FloydSteinbergDitherMethod. return: [MagickBooleanType!] ] ] ] | Mon 8:41 |
| 5193 | Oldes | Endo - I'm sure that in a real life. you don't want to use #enum to define values like a, b, c, d as well as common names like red, blue etc.. Real life enum example naming is for example: #enum DitherMethod! [ NoDitherMethod RiemersmaDitherMethod FloydSteinbergDitherMethod ] | Mon 8:38 |
| 5192 | Oldes | "*** Compilation Error: unknown directive enum" = should I fix it to provide correct error message? | Mon 8:33 |
| 5191 | Dockimbel | I mentioned it above, it needs a fix in the compiler and/or the runtime code. | Sun 23:08 |
| 5190 | Endo | "Can you make a red global var.." No, we cannot. "document fixed", still we cannot compile the examples on Windows, because of "redeclaration of c" in win32.reds file. | Sun 23:02 |
| 5189 | Dockimbel | Specification document fixed. | Sun 22:54 |
| 5188 | Dockimbel | Can you make a `red` global variable in C when `red` is already use as an enumeration value? | Sun 22:53 |
| 5187 | Endo | Even in C we specify where we take the value, enum color {red,green}; color col = red; <-- col declared as a color. red is not defined as global. | Sun 22:49 |
| 5186 | Dockimbel | The reason enumerations were added by Oldes was just to simplify the writing of some bindings which heavily rely on enumerations. | Sun 22:44 |
| 5185 | Endo | Ok. So we at least need to fix the examples on the web page. | Sun 22:44 |
| 5184 | Dockimbel | Currently, no. | Sun 22:43 |
| 5183 | Endo | compiler fails when including both file. | Sun 22:43 |
| 5182 | Endo | so no chance to compile something like: #enum colors [red blue] ;in file 1 #enum tests [red green] ;in file 2 | Sun 22:43 |
| 5181 | Dockimbel | That's the way C works, the enumerations in Red/System is a direct transposition, works the same way. | Sun 22:42 |
| 5180 | Endo | in many other language we should give the name of the enumaration to get a value from it. without using this way, it is almost impossible to use enumarations without a clash. | Sun 22:41 |
| 5179 | Dockimbel | "red" is global => yes. | Sun 22:40 |
| 5178 | Dockimbel | Enumerations as namespace: why not...needs some deeper analysis to see if its consistency with the rest of the semantic rules and if the implementation does not disturb existing compiler code too much. | Sun 22:40 |
| 5177 | Endo | How do we know that "red" is an enumaration from "colors", if we don't use "a: colors/red" or somethink similar? | Sun 22:40 |
| 5176 | Endo | where it should be declared then? in the example on the web site:
#enum colors [red blue green yellow]
a: red "colors" used nowhere, so "red" is global. No? | Sun 22:38 |
| 5175 | Dockimbel | Redeclaration of c: it seems to be an internal issue, `c` should not be declared in global context. | Sun 22:36 |
| 5174 | Dockimbel | No, the name should be colors! and the purpose was to use is as a pseudo-type when declaring an argument or a return value. | Sun 22:35 |
| 5173 | Endo | it is very difficult to declare an enum without a name-clash, if <name> is not used. | Sun 22:35 |
| 5172 | Endo | shouldn't it be #enum colors [a b c] print-wide [colors/a colors/b colors/c] | Sun 22:34 |
| 5171 | Endo | and if #enum colors [a b c] declares a,b,c; then why we need a <name>? | Sun 22:33 |
| 5170 | Dockimbel | You're right, I'm not used to enums yet. :-) | Sun 22:32 |
| 5169 | Endo | needs to be fixed on the web page only. | Sun 22:32 |
| 5168 | Endo | in the tests there is no missing name I think. | Sun 22:31 |
| 5167 | Endo | in first example enum <name> is missing and it gives "unknown directive enum" error. | Sun 22:31 |
| 5166 | Dockimbel | I even get "*** Compilation Error: unknown directive enum" when testing it. :-) I was wondering if I haven't introduced some regressions when merging the float-partial branch, but all the enum tests are running fine... | Sun 22:30 |
| 5165 | Endo | Its given as example for #enum directive, but it cannot be compiled. #enum [a: 1 b c d: e: 10] ;<--- missing <name> print-wide [a b c d e] #enum colors [A B C D E] ;<--- redeclaration print-wide [A E] | Sun 22:26 |
| 5164 | Endo | I see, so it should be corrected on the web page, Red/System Language Specification. | Sun 22:23 |
| 5163 | Kaj | That's a name clash | Sun 22:21 |
| 5162 | Endo | #enum colors [a b c] | Sun 22:21 |
| 5161 | Endo | when I compile following line, I got "*** Compilation Error: redeclaration of enumerator c from colors" #enum [a b c] print-wide [a b c] | Sun 22:19 |
| 5160 | Kaj | I've added Mandelbrot drawing floating point examples to the C library binding, for Red/System and seven other languages, to compare them | Sun 18:51 |
| 5159 | Dockimbel | I would like a less formal syntax description if possible. I would like to remove all the `+`. | Fri 20:39 |
| 5158 | Kaj | #enum <name>! [ (<label> | <label>: + <value>) + ] | Fri 20:32 |
| 5157 | Kaj | I'm not sure what grammar syntax you use and what exactly #enum supports, but something like this? | Fri 20:32 |
| 5156 | Kaj | Interesting, thanks for the explanations | Fri 20:30 |
| 5155 | Oldes | I think that single precision is used mostly on GPUs as you can have up to 2 single float operations per clock. | Fri 20:03 |
| 5154 | Dockimbel | "Doesn't that syntax spec preclude the mixing of value labels and non-value labels?" Yes it does. I should rewrite the syntax definition to be more accurate and more readable...any suggestion? | Fri 18:42 |
| 5153 | Dockimbel | Single precision purpose: I guess the only advantage is smaller storage size. Some Intel FPU operations are even slower in single precision than double precision. | Fri 18:37 |
| 5152 | Dockimbel | See http://en.wikipedia.org/wiki/Type_conversion#Type_promotion "C and C++ perform such promotion for objects of boolean, character, wide character, enumeration, and short integer types which are promoted to int, and for objects of type float, which are promoted to double." | Fri 18:35 |
| 5151 | Kaj | Are enumeration names pseudo-types equivalent to integer!? I guess so, but the documentation doesn't say | Fri 17:14 |
| 5150 | Kaj | Doesn't that syntax spec preclude the mixing of value labels and non-value labels? | Fri 17:09 |
| 5149 | Kaj | #enum <name>! [ <label> + | <label>: + <value> ] | Fri 17:09 |
| 5148 | Kaj | That seems odd to me. What's the point of single precision, then? It would be slower than double precision | Fri 17:06 |
| 5147 | Dockimbel | "but C automatically converts them to double" => "but C always expects double" | Fri 17:04 |
| 5146 | Dockimbel | Kaj: you can pass single precision values to C functions, but C automatically converts them to double. C always passes single precision floats as double precision, and converts them before pushing them on stack. | Fri 17:04 |
| 5145 | Kaj | Thanks | Fri 17:02 |
| 5144 | Dockimbel | Docs updated. | Fri 17:02 |
| 5143 | Dockimbel | Sorry, forgot to update the docs online. | Fri 16:58 |
| 5142 | Kaj | Have the docs been republished yet? The #enum link points to #include | Fri 16:55 |
| 5141 | Kaj | Does that mean that external functions that use single precision can't be bound? | Fri 16:42 |
| 5140 | Kaj | "For non-variadic C functions, Red/System's compiler will promote float32! to float! automatically." | Fri 16:42 |
| 5139 | Kaj | Thanks, but I'd rather not do that | Fri 16:24 |
| 5138 | Dockimbel | Kaj, in any case, you can just replace #{037B} by #{037F} in IA-32.r at line 20: fpu-flags: to integer! #{037B} | Fri 16:23 |
| 5137 | Dockimbel | Pekr: it is possible to divide by zero in IEEE-754, that gives you +/- INF. I have not decided yet how it should be handled in Red/System, I would be in favor of raising an error rather than introducing INFs. | Fri 16:21 |
| 5136 | Kaj | Yes, that would be good, otherwise I don't have a browser anymore | Fri 16:21 |
| 5135 | Dockimbel | Kaj: I will see if I can quickly add support for `system/fpu/flags` so users can set it as they want/need. | Fri 16:19 |
| 5134 | Pekr | You should not divide by zero, it gives an error :-) | Fri 16:18 |
| 5133 | Kaj | What's the decision on divide-by-zero? | Fri 16:16 |
| 5132 | Pekr | what is C init routines topic about? I mean - why Red/System needs it? | Fri 16:14 |
| 5131 | Dockimbel | Almost, I need to have a look at C init routines first, probably tonight or tomorrow, then I'm free to work on Red. ;-) | Fri 16:10 |
| 5130 | Pekr | So now you are finally free to start working on Red? :-) | Fri 16:09 |
| 5129 | Dockimbel | Typo fixed thanks. | Fri 16:07 |
| 5128 | Pekr | "datatype implement" should be "datatype implements" imo ... | Fri 15:32 |
| 5127 | Kaj | Sigh, the state of computing | Fri 14:56 |
| 5126 | Dockimbel | If I disable the float "divide by zero" exception, we'll have no way to detect it until proper support for INF will be added. | Fri 14:56 |
| 5125 | Kaj | This is on Syllable Server, where it worked before | Fri 14:54 |
| 5124 | Dockimbel | The browser runs fine here on Ubuntu 10.04. No divide by zero errors. | Fri 14:53 |
| 5123 | Dockimbel | Yeah, same issue than previously with the "float invalid operation" exception. Webkit seems to mask them all, while Red/System let them pop up. | Fri 14:50 |
| 5122 | Kaj | 0MQ works again | Fri 14:47 |
| 5121 | Kaj | *** Runtime Error 7: float divide by zero *** at: B01DE1F6h | Fri 14:46 |
| 5120 | Kaj | Now the WebKit browser starts loading the Red site, but halfway I get this: | Fri 14:46 |
| 5119 | Kaj | Not that I found | Fri 14:37 |
| 5118 | Dockimbel | Kaj: fix pushed for the 0MQ issue. Let me know if it works fine for you now. Also, any other regression to fix before releasing the new version? | Fri 13:59 |
| 5117 | Kaj | The WebKit I use of a few years old is 18 MB installed size, on Syllable Server. It has quite a few more dependencies, though, and on Windows that would be more because none of the dependencies are preinstalled | Fri 13:42 |
| 5116 | Kaj | Ah, another one of those. It must be a regression, that's why I've seen it before | Fri 13:38 |
| 5115 | Dockimbel | Kaj: found the issue with 0MQ, it's related to integer! => logic! type casting in your wrapper functions. It seems that the runtime conversion code is not emitted. | Fri 13:37 |
| 5114 | Dockimbel | I'm looking into the 0MQ error messages... | Fri 11:59 |
| 5113 | Dockimbel | The webkit libs on Windows seems to weight ~66MB. | Fri 11:45 |
| 5112 | Dockimbel | It wraps the webkit component of GTK, so you can add a webkit view in a GTK window and pass it an URL to open. As we already have a pretty broad support of GTK components, you can now build your own custom web browser in Red/System! | Fri 11:44 |
| 5111 | Pekr | Yes, I just realised it today :-) But my friend told me something like WebKit library having 100MB? (maybe a typo) So I expected the wrapper being thousandns of lines, whereas it is just few functions :-) So what kind of wrapper do we have? It surely is not complete wrapper to all the WebKit functionality? | Fri 11:16 |
| 5110 | Dockimbel | Pekr: don't you know that we already have a GTK-webkit-powered web browser? :-) | Fri 11:02 |
| 5109 | Dockimbel | Kaj: issue fixed. | Fri 11:00 |
| 5108 | Pekr | We have wrapped Webkit? :-) It is just yesterday when my friend reported to me, trying to write some basics of media playback, that downloading new version of Webkit broke Python binding, hence I would expect some incompatibilities between the releases :-) (R/S one had probably different reasons) | Fri 10:18 |
| 5107 | Dockimbel | Ok, found the culprit bit in the exception mask. | Fri 10:04 |
| 5106 | Dockimbel | It seems that the issue is caused by FPU control word settings used by Red/System that make webkit crash. I need to find a common setting that would work for both. | Fri 10:00 |
| 5105 | Dockimbel | I messed up SSE and MMX in my posts above, it's MMX that shares hardware with x87 and not SSE. | Fri 9:59 |
| 5104 | Kaj | OK, good luck | Thu 23:07 |
| 5103 | Dockimbel | I'll search deeper tomorrow, sleep time now. I'll postpone the 0.2.4 release until I get a clearer view on this issue. | Thu 23:07 |
| 5102 | Dockimbel | I wonder if activating the Intel FPU in x87 mode, then using SSE instructions (in libwebkit) could trigger such error. IIRC, the FPU needs to be properly set in x87 or SSE mode before using an x87 or SSE instruction. | Thu 23:04 |
| 5101 | Dockimbel | I was thinking that libwebkit might be calling some of them in some way. | Thu 23:01 |
| 5100 | Kaj | Well, they're still not called :-) | Thu 23:00 |
| 5099 | Dockimbel | I am not sure, but it might be a collision with C init routines. | Thu 22:59 |
| 5098 | Kaj | The other bindings are OK | Thu 22:58 |
| 5097 | Kaj | I was suspecting something like that | Thu 22:58 |
| 5096 | Dockimbel | If I remove the x87 FPU init code, the crash disappears. | Thu 22:56 |
| 5095 | Kaj | OK, thanks. 11.10 is the culprit. Not that it would crash, but the library names and versions have changed | Thu 22:50 |
| 5094 | Dockimbel | Ubuntu 10.04 LTS. | Thu 22:49 |
| 5093 | Kaj | What Linux distro? I ask because the WebKit in the newest Linux Mint is incompatible | Thu 22:48 |
| 5092 | Dockimbel | Webkit crash: reproduced on Linux. | Thu 22:47 |
| 5091 | Kaj | It must somehow be unable to do cleanup, or the cleanup has already occurred. But the same code ran OK on earlier Red versions | Thu 22:47 |
| 5090 | Dockimbel | 0MQ messages: I can see them on Windows too, do you have an idea on what causes them? | Thu 22:46 |
| 5089 | Kaj | It seems that the newest WebKit versions have broken compatibility | Thu 22:45 |
| 5088 | Dockimbel | Webkit: can't run it on Windows, I was able to get a suitable libwebkit but it fails to find some functions in the dependent DLL. Trying on Linux. | Thu 22:44 |
| 5087 | Kaj | I've seen that before during development, but it had been fixed for quite some time. It must be generated during cleanup | Thu 22:41 |
| 5086 | Kaj | bash-4.0# ./request-client
0MQ version: 2.1.4 Connecting to Hello World server... Sending request 1 Received reply 1: World Resource temporarily unavailable Sending request 2 Received reply 2: World Resource temporarily unavailable Sending request 3 Received reply 3: World Resource temporarily unavailable Sending request 4 Received reply 4: World Resource temporarily unavailable Sending request 5 Received reply 5: World Resource temporarily unavailable Sending request 6 Received reply 6: World Resource temporarily unavailable Sending request 7 Received reply 7: World Resource temporarily unavailable Sending request 8 Received reply 8: World Resource temporarily unavailable Sending request 9 Received reply 9: World Resource temporarily unavailable Sending request 10 Received reply 10: World Resource temporarily unavailable Resource temporarily unavailable Resource temporarily unavailable | Thu 22:40 |
| 5085 | Kaj | I'm also getting weird error messages on 0MQ, although it basically works: | Thu 22:40 |
| 5084 | Dockimbel | Looking into it... | Thu 22:26 |
| 5083 | Kaj | bash-4.0# ./LazySundayAfternoon-Browser *** Runtime Error 9: float invalid operation *** at: B66C5447h | Thu 22:06 |
| 5082 | Kaj | There's a problem with the WebKit binding: | Thu 22:05 |
| 5081 | Kaj | Petr, that library is weird, and I guess the Windows environment makes it even weirder. The interface is so convoluted that I assumed the reason was to export normal C functions, so maybe that's the case after all | Thu 20:16 |
| 5080 | Kaj | Will do. Fortunately, I just got the new Syllable development release out the door | Thu 20:07 |
| 5079 | Kaj | "Kaj: I did a few tests for the 0.2.4 candidate with some of your bindings on Windows and Linux. No issue so far. Could you please check if all your bindings latest versions are working fine before I make the release?" | Thu 20:07 |
| 5078 | Pekr | just a note - solved the ledctrl problem. I noticed it generated system.con configuration file, but this file was just 210 bytes. So I copied over the larger one from real set-up, and those affected functions started to work. Tomorrow I will try directly with the ledscreen. So, although the library is said to be C++ only, it now works even from R2. | Thu 17:30 |
| 5077 | Andreas | I don't think so :) | Thu 15:16 |
| 5076 | Steeve | No I have no problem with that , I just fear Github will not be happy :-) | Thu 15:14 |
| 5075 | Andreas | Then what is it you "don't want to delete"? | Thu 15:13 |
| 5074 | Steeve | No | Thu 15:13 |
| 5073 | Andreas | Do you have local changes you want to keep? | Thu 15:12 |
| 5072 | Steeve | I tried to resync my repository but lot of errors pop up. Can I rebuild a clean version without deleting my fork first ? | Thu 15:10 |
| 5071 | Dockimbel | The runtime error handler now better catch unknown errors and the use of SWITCH has decreased the runtime code size significantly. | Thu 14:23 |
| 5070 | Pekr | I just posted the result so that Doc could see, that now the error message is different (more concrete?). Did anything changed internally apart from float support? Also - before 0.2.4, the output exe was 61xx bytes, whereas with 0.2.4 is 5632 bytes ... | Thu 14:13 |
| 5069 | Pekr | Maxim: thanks, that was my idea. Will learn a bit of C too :-) | Thu 14:12 |
| 5068 | Dockimbel | Kaj: I did a few tests for the 0.2.4 candidate with some of your bindings on Windows and Linux. No issue so far. Could you please check if all your bindings latest versions are working fine before I make the release? | Thu 13:51 |
| 5067 | Maxim | pekr, in this case, wrap another dll around it, a.k.a. "thin layer" dll. use a C++ compiler, but use the functions within a C sourced dll project. this dll will then serve as your translation from the C++ libs to Red/Rebol whatever. If the C++ use requires special steps on function entry/exit, the compiler will add these for you (when it compiles) and from outside the C function you'll be back into "normal land". I've even read that some C++ compilers can't even properly use libs from a different C++ compiler. | Thu 13:22 |
| 5066 | Pekr | OK, case closed - I got reply from Linsn, that the library is compiled to be used only by C++ compilers. Strange that half of the functions work correctly though (was able to turn led screen on/off for e.g.) | Thu 6:51 |
| 5065 | Pekr | Sorry, wrong cut and paste. The first error was: Compiling led/led.reds ... Script: "Red/System IA-32 code emitter" (none) *** Compilation Error: return type missing in function: led-set-language *** in file: %led/led.reds *** at line: 87 *** near: [led-set-language 3 lf] | Thu 6:47 |
| 5064 | Pekr | I am able to disrupt R2 compilation session to the state, where its restart is needed. Not a big deal, but maybe you will see something obvious. The code causing it is as follows: print ["led-set-language: " led-set-language 3 lf] The trouble is, that led-set-language does not return any value (void). This is understandable, that 'print has problem with such a clause. The error returned was: Compiling led/led.reds ... Script: "Red/System IA-32 code emitter" (none) *** Compiler Internal Error: Script Error : Out of range or past end *** Where: resolve-path-head *** Near: [second either head? path [ compiler/resolve-type path/1 ]] Correcting the issue (moving function call away from the print block, I get another error: Compiling led/led.reds ... Script: "Red/System IA-32 code emitter" (none) *** Compiler Internal Error: Script Error : Out of range or past end *** Where: resolve-path-head *** Near: [second either head? path [ compiler/resolve-type path/1 ]] This error repeats, untill I restart the R2 compiler session, which is a proof, that I corrected the source code, as aftern the R2 restart, I can get clean pass ... | Thu 6:46 |
| 5063 | Pekr | Downloaded new branch, and now my error message changed. Was there any change to error handling? *** Runtime Error 101: no value matched in SWITCH *** at: 004013ADh | Thu 6:33 |
| 5062 | Dockimbel | FYI, I am currently merging the float-partial branch and preparing for the 0.2.4 release. | 15-Feb 16:44 |
| 5061 | Pekr | Doc - I did not like ?? eiher, looked weird. Nor did I liked print-line, so I adopted "print [something lf]" block aproach, which looks ok to me ... | 15-Feb 8:41 |
| 5060 | Kaj | It does mean "print word value" in REBOL | 14-Feb 23:09 |
| 5059 | Dockimbel | After using `??` a few hours, I realized that it was a mistake to use it as a shortcut for `print-line`. It is readable when used on a word, but with a block, it looks too esoteric and hurt the feelings of old rebolers that see it as a syntax error. So, I want to get rid of `??` but can't find anything to replace it that would be both short and consistent with `print`and `print-line`. I think that I'll just deprecate `??` but won't remove it for now as some of you are heavily using it. | 14-Feb 22:34 |
| 5058 | Dockimbel | Evgeniy: it seems you've missed my post at 10:40:23 earlier today. | 14-Feb 22:26 |
| 5057 | Dockimbel | Adding dead code elimination in Red/System at this point of the project serves no purpose. Please re-read all the presentations slides, roadmap, discussions on the ML or here... | 14-Feb 22:20 |
| 5056 | Oldes | I'm really looking for to see your version Evgeniy. It's always good to see different approaches for same tasks. | 14-Feb 14:17 |
| 5055 | Pekr | :-) We are just starting ... but you could help Carl to improve R3 semantics :-) | 14-Feb 13:51 |
| 5054 | Evgeniy Philippov | Oldes: And as Red/System is open, everybody can provide own version:) Evgeniy: It seems to be necessary. I won't be attached to a language with a preprocessor. That's UNDERTHOUGHT OUT language. | 14-Feb 13:46 |
| 5053 | Evgeniy Philippov | Steeve: The Red/system's compiler is not that far advanced. It can't perform dead code analysis. it's why it will get stuck with macros. Evgeniy: dead code analysis for boolean constants is fairly simple and straigtforward I could even help write the only thing necessary is a boolean flag for a value that it is a CompileTimeConstant if we have "IF(value)" and value is FALSE, we just remove the false code branch from memory. And do not output code for it. This renders #if useless... Steeve: Yeah it seems pretty straightforward, feel free to ask in #Red :-))))) Evgeniy: In Oberon, you can write VAR Procedure1: PROCEDURE1; BEGIN IF (ARCH1) Procedure1:=Arch1Module.Procedure1 ELSE Procedure1:=ArchOther.Procedure1 END END that's not so simple: there can be absent libraries and headers and files in dependent files on different archs. This must be taken into account and makes an implementation slightly complex. Steeve, I've already asked that by previous discussion. I thought that this technique is obvious. | 14-Feb 13:39 |
| 5052 | Pekr | OK, thank, that just clears the situation for me a bit .... | 14-Feb 12:53 |
| 5051 | Dockimbel | "Btw - if some func retunrs void, how should my return value look?" Void is the C way to indicate "no return value". In Red/System, you just don't add a RETURN: clause in such case. | 14-Feb 12:42 |
| 5050 | Pekr | Also - what is a difference in passing a "void" to func, and passing it no value? Aren't following definitions just the same? typedef void (WINAPI *LSN_BRIGHTDLG)(void); typedef int (WINAPI *LSN_GETBRIGHT)(); | 14-Feb 12:16 |
| 5049 | Pekr | Btw - if some func retunrs void, how should my return value look? | 14-Feb 12:15 |
| 5048 | Pekr | It is a pity that my first attempt has some such problems. Just don't loose the time with it, if you have more important stuff to do. Kaj tried to do his best here, ditto Andreas. | 14-Feb 12:14 |
| 5047 | Pekr | I think too, it is not a Red/System. I used the generated exe also on a LED screen PC. I can turn screen on/off, led-is-power? works correctly, ditto for led-is-locked?, but led-get-brightness fails ... so if some functions work, it means that DLL has properly exported values? All use the same declaration ... | 14-Feb 12:13 |
| 5046 | Dockimbel | LedCtrl.dll (from ledset-source package): 1) How is it supposed to react if a board is not connected? 2) The DLL is a C++ program with static functions (acting as wrappers I guess). Have these static functions been compiled with an "extern C" directive? If not, there's no chance it can work with anything other than a compatible C++ compiler. I think that the crash has nothing to do with Red/System, the "unknown" error might be caused by the DLL functions corrupting the data segment of the Red/System binary where the runtime error data is located. I will try to track it anyway, just to be sure, it's not a missing code in the Red/System runtime error processing routine. | 14-Feb 12:07 |
| 5045 | Pekr | As for the return value - I was switching between R2, Red, World, so not sure, but ommiting return clause raised an error. Not sure it was Red or other environment. Will try that ... | 14-Feb 12:06 |
| 5044 | Pekr | Doc - I use text editor too, for some complex stuff.Yet for trial and error I use console. Several users expressed in the past, that one of the nice values of R2 is its console, for the quick prototyping around. | 14-Feb 12:06 |
| 5043 | Dockimbel | "Btw - how do I wrap properly function, which does not return any result? I tried just without the return clause, but it is not possible. Is e.g. return: [] (empty block allowed?)" It's in the spec document and same as the routine! interface in R2, just do not put a RETURN: definition if the function does not return anything: http://static.red-lang.org/red-system-specs.html#section-14.1 | 14-Feb 11:53 |
| 5042 | Dockimbel | " it is about the process of building app vs dynamic prototyping using interpreter" Well, I don't know how you build apps, I have never built one from the console, but only from a code editor. Console is nice for testing some small snippets when unsure, but coding is usually done in a decent code editor, where you usually launch your script using a shortcut. From that POV, there will be no differences with Red for the users. And to avoid further misunderstanding, Red will have a console, like R2 does, with similar features and possibilities. | 14-Feb 11:48 |
| 5041 | Dockimbel | Compilation time: absolute speed is not the issue currently, we're talking about relative speed of the preprocessing compared to whole compilation time. | 14-Feb 11:42 |
| 5040 | Dockimbel | Pekr: I will test your lib later today and see what's wrong. As I read that it crashes with also R2 and World, it seems obvious that something is wrong (a) in the lib or (b) you're not passing the right arguments or (c) you're not calling the right functions in the right order. | 14-Feb 11:39 |
| 5039 | Pekr | As for compilation time. I don't know guys, but Red/System compiles REALLY fast. I do remember my dos times, where compiling took 30 secs. Where's the problem? It's not imo about the compilation speed, at least for me - it is about the process of building app vs dynamic prototyping using interpreter. I don't like much the compile/build/run process, but I expect something like R2 console for prototyping appear in distant future for Red .... | 14-Feb 10:02 |
| 5038 | Pekr | Doc - we have got the right function names, that is not the problem. The problem is the crash, and we were trying to identify, if Red/System library wrapping system still needs some improvements for some cases, or simply the DLL is doing something internally, that some functions work, and some crash. Here's example: fpGetBright= (LSN_GETBRIGHT)GetProcAddress(g_hLedCtrlInst, "LSN_GetBright"); wrapped as: led-get-brightness: "LSN_GetBright" [return: [integer!]] Btw - how do I wrap properly function, which does not return any result? I tried just without the return clause, but it is not possible. Is e.g. return: [] (empty block allowed?) | 14-Feb 10:00 |
| 5037 | Oldes | I was not using preprocessor in my Rebol/Flash dialect and I must say, I find the Red/System way useful. It may be true, that additional pass may slow the compilation a little bit, but it also provide additional features. Also I don't expect that it will be used in some huge projects with MB of sources so if it's a few ms slower is not a problem. And as Red/System is open, everybody can provide own version:) | 14-Feb 9:42 |
| 5036 | Dockimbel | Also, the plan for me since the beginning was to use Red to help construct dynamically Red/System programs without requiring any preprocessor. As Red is not ready yet, I'm glad we have the preprocessor now in Red/System, to make our life easier. | 14-Feb 9:40 |
| 5035 | Dockimbel | Pekr: the "make" vs "declare/alias" topic has been discussed lengthly in the ML, please read the posts there. | 14-Feb 9:36 |
| 5034 | Dockimbel | Pekr: you've mixed up completly "load-time" and "run-time" library loading. You don't need a library handle at "load-time" (unless you want to hack something in the OS). Also, you don't need any of your code above, just the #import declaration with the right function names (finding the right names seems to be the most complex part in the case of the library with the weird API you're using) | 14-Feb 9:33 |
| 5033 | Dockimbel | Evgeniy: (short answer) 1) IIRC, there's no recompilation of included files in Red/System, the only overhead is parsing the preprocessor directives and reducing them. I agree that the whole compilation process would be significantly faster without a preprocessor, but that's another topic. 2) Preprocessor is a handy addition for compiled languages, that's why it was introduced in Red/System, not because it was a planned feature, but just because we _needed_ it for going further. The distinctive # prefix is used to make it clear both for users and the compiler that these parts are reduced at "compile-time" instead of "run-time" and avoid confusing both users and the compiler. For example, from your examples, the compiler has no way to distinguish a "compile-time" IF from a "run-time" IF, unless you make it a lot slower by doing static analysis and complex inference (the cost would be huge compared to the preprocessor). Also, this might also introduce a lot of new restrictions in the language semantics, which is not desirable. 3) IMPORT is better than INCLUDE: you might have missed it, but we can't yet generate libraries, so importing Red/System code now is not an option. | 14-Feb 9:30 |
| 5032 | Pekr | OK, so if I understand it correctly, Red/System loads the library at an executable load time, whereas load/library does so dynamically in the app run-time. Stil - I wonder, if we could get a handle to such a library? I mean, syntactically #import is just like preprocessor construct - you can't assign it to any variable. Not sure it would be usefull, to be able to retrieve a handle to such wrapped library plus handles (entry points) to wrapped function calls? | 14-Feb 9:24 |
| 5031 | Pekr | here's what he meant: "get-proc-address should really be defined as return: [function!] but that's not currently supported" | 14-Feb 9:19 |
| 5030 | Pekr | We tried to manual load library and get the proc address to be able to wrap a function, which crashes Red (as well as REBOL, World). It might be, that the library is not properly constructed for such a case. But Kaj mentioned something like parameter being a function! type, which is not supported, nor do we know, if it is planned, or if it even help our case .... | 14-Feb 9:17 |
| 5029 | Dockimbel | But all the OS and third-party libraries we're currently using in Red/System have stable API, not the need for runtime loading has not appeared yet. | 14-Feb 9:15 |
| 5028 | Dockimbel | or extending an app by loading "plugins" at runtime. | 14-Feb 9:13 |
| 5027 | Dockimbel | The only added benefit of manual loading at runtime is being able to upgrade the library without having to recompile the main program. | 14-Feb 9:13 |
| 5026 | Dockimbel | Pekr: (short answer) Red/System (and Red) generate executable binaries while R2/R3, while World and all other interpreted languages just run code in an interpreter or VM. This is a big difference, because Red can use the OS to load libraries at "load-time" instead of having to write code to do it (as all others interpreted languages require). This is also faster than loading manually. Red/System doesn't have yet a x-platform extension for adding "run-time" library loading support, just because we don't need it at all for now, but it can be added easily, by wrapping libFFI for example, or implementing it purely in Red/System. | 14-Feb 9:11 |
| 5025 | Endo | Welcome back Doc! | 14-Feb 9:08 |
| 5024 | Pekr | It all started by me trying to wrap some specific case. That's probably the most importat - Red allowing to wrap more outer world. As for syntax and other sugar, that's a secondary ... for now :-) | 14-Feb 9:01 |
| 5023 | Pekr | :-) yeah, we generated quite a lot of a stir here. At least you know, that Red is a lively project :-) | 14-Feb 9:00 |
| 5022 | Dockimbel | Back from my trip to Paris, took me 3 days to come back home (Montenegro) due to huge snow. All roads closed, no train/bus/plane, state of emergency declared since saturday. I will answer the questions brought by Pekr and Evgeniy here later today, when I'll finish reading all the posts and emails I got since a week. | 14-Feb 8:59 |
| 5021 | Evgeniy Philippov | But I am sure that NO strategy justifies #include and NO strategy is speedier than IMPORT of a compiled library. | 14-Feb 5:41 |
| 5020 | Evgeniy Philippov | Ok | 14-Feb 5:39 |
| 5019 | PeterWood | Whilst I cannot speak for Nenad, I'm sure he will recognise these advantages. He may of course have other strategies up his sleeve to achieve speedy compilation. Whether he would choose to improve the bootstrap version of Red/System at the expense of delaying work on Red is the big question. | 14-Feb 4:50 |
| 5018 | Evgeniy Philippov | I.e. after each #define and after it the #include, we would need to recompile the included file. That's enourmous lossage of time and resources. | 14-Feb 4:36 |
| 5017 | Evgeniy Philippov | My approach would also decrease a number of layers by one. This greatly reduces the complexity and greatly improves compilation speed. | 14-Feb 4:34 |
| 5016 | PeterWood | I feel that there is a lot of merit in Evgeniy's approach, not least the possibility of a one-pass compiler. I think it is worth remembering that the current version of Red/System is a "bootstrap" version with which to build Red. Once Red is built, Red/System will be re-written in Red. It is most likely that there will be many imporvements to Red/System , some may involve syntax changes. I feel we should all expect to have to re-visit existing Red/System code when the "real" Red/System is released. | 13-Feb 22:52 |
| 5015 | Maxim | Pekr, Red and Red/System don't have the same semantics so I see no reason why they have to be compatible in any way except lexically. | 13-Feb 22:20 |
| 5014 | Kaj | Then you remember wrong. It's easy to reread above here | 13-Feb 22:07 |
| 5013 | Pekr | Explain ... that is how I remember the decision point ... | 13-Feb 22:07 |
| 5012 | Kaj | That is total nonsense | 13-Feb 22:06 |
| 5011 | Kaj | Please point to the "protected" C equivalents | 13-Feb 22:06 |
| 5010 | Pekr | The decision was based clearly upon the fear, that Red/System is going to be used mainly by C ppl, and that in C print doeas not add new line by default ... that is imo a wrong design decision ... | 13-Feb 22:06 |
| 5009 | Pekr | That is what I call a protecting C nonsense. We are REBOL, not C, period. I am so mad about it, that if there would not be option to use print along with block, I would stop using Red/System ... | 13-Feb 22:05 |
| 5008 | Kaj | What does that have to do with C? | 13-Feb 22:05 |
| 5007 | Pekr | It does :-) It does not print newline by default, although it will be 90% time of requested feature. Just because the compatibility to C, Doc introduced print-line, which will be equivalent to ??. So 90% of your time your code is going to be ridden with print-line or ??, becaue we don't like 'prin ... | 13-Feb 22:04 |
| 5006 | Kaj | The print names have nothing at all to do with C | 13-Feb 22:01 |
| 5005 | Pekr | Max, I share some sentiments with Evgeniy. I too don't understand some design decisions - my first take is, that Red/System should be as much compatible to Red, as possible. Hence I will never agree to decision for 'print differing from its Red counterpart. I don't give a <censored> to C users, as imo noone will use Red/system, unless that person also plans to use Red itself. My take is, that compatibility between Red and Red/System is much more important, that compatibility between the Red/System and C. Ditto the strange aproach to use kind of preprocessor for importing the libraries, whereas R2 and World are OK with just make routine! Ditto for strange declaration stuff: declare struct! alias struct! #import for a library Intead of: make struct! make lit-struct! make routine! If Red/System is going to be inlined in Red, the aproach to costructors should be as much the same as possible. This is a dialecting - the same words have different meaning in different context usage. I don't give a <censored> about protecting a possible C user's knowledge ... | 13-Feb 21:57 |
| 5004 | Maxim | AFAICT, Red/system is used more like a high-level VM (compilable source rather than interpreted opcodes) which can be natively compiled. RED won't have RED/System semantics. | 13-Feb 20:34 |
| 5003 | Evgeniy Philippov | Maxim, from a R/S spec: "Red/System ... will be embedded in Red scripts" " | 13-Feb 20:24 |
| 5002 | Evgeniy Philippov | This is related to RED only. I can discuss privately with Dockimbel, but why should I go private? | 13-Feb 20:18 |
| 5001 | Evgeniy Philippov | that's not analysable. Into which thread? | 13-Feb 20:17 |
| 5000 | Evgeniy Philippov | either macroname [ c ] [ d ] | 13-Feb 20:17 |
| 4999 | Steeve | And we should switch the discussion into another thread | 13-Feb 20:16 |
| 4998 | Evgeniy Philippov | #either macroname cond [ a if macroname ] [ b if macroname ] either macroname | 13-Feb 20:15 |
| 4997 | Evgeniy Philippov | for example how to analyse this: | 13-Feb 20:14 |
| 4996 | Steeve | Okkkkkk, I know what the word means in its regular sense. I just feel you should make clear yourself with the context and provide some use cases. | 13-Feb 20:13 |
| 4995 | Evgeniy Philippov | That's reduction of meaning of a program. Reduction of its semantics. | 13-Feb 20:11 |