World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Pekr 28-May-2009 [14490] | As for 4) - I know you guys find them important (utypes). But what will we gain having the ability to do our own datatypes? btw - having own datatype will have to fulfill some needs, as for e.g. utype will have to be able to react to some functions? |
BrianH 28-May-2009 [14491] | Plugins are pretty much modules, but with the possibility of native code. |
Henrik 28-May-2009 [14492] | do devices wrap hardware directly like a real device driver or does it wrap the underlying OS driver? |
BrianH 28-May-2009 [14493] | We need utypes for host interoperability, to replace rebcode, and more. A utype will need to be able to react to the actions, just like a type |
Dockimbel 28-May-2009 [14494] | Re 1): Pekr, it's the same difference than driver vs library for an OS. |
BrianH 28-May-2009 [14495] | Henrik, yes, in theory either. R3 is built like an OS. |
Pekr 28-May-2009 [14496] | But - I can imagine having library containing functions to handle mouse, but Amiga had device for each, which allowed it to function in a more async way ... |
BrianH 28-May-2009 [14497] | Right. R3 is built like an OS. And designed by the same guy who designed *that* OS. It might follow a similar model. |
Henrik 28-May-2009 [14498] | this will probably be most useful on embedded or specialized hardware for now |
BrianH 28-May-2009 [14499] | The device will have associated functions, but those functions might be defined in a plugin. Or not. |
Dockimbel 28-May-2009 [14500] | R3 devices wrap OS API (or third-parties API), no direct hardware access, that's way too costly to achieve. |
BrianH 28-May-2009 [14501] | Too costly on host OSes, you mean. Some host OSes provide APIs that structure hardware access, like the Direct* APIs. Devices could use those. Or if R3 is just running on a bootloader (as proposed in Wildman), the device functions would access hardware directly. |
Pekr 28-May-2009 [14502x2] | Brian - ticket #588 does not crash here. It just takes lots of time and resources to display 20x9999999 size button :-) |
it is related to other bug, which is marked as Tested already. We should close this one probably too ... | |
BrianH 28-May-2009 [14504x2] | OK, I'll mark it as tested for the same alpha. |
Done. | |
Dockimbel 28-May-2009 [14506] | About #564 and blog#207: I'm a little lost, is option 3 already implemented in alpha55? |
BrianH 28-May-2009 [14507] | No, most of 2 is already implemented. |
Dockimbel 28-May-2009 [14508x2] | Ok, after testing and reading again your comment in #564, my example in blog's article is wrong, it should have been : >> if any [get/any 'tst 123] [print "ok"] ok |
My example raises an error (as it should do) : >> if any [tst 123] [print "ok"] ** Script error: tst has no value ** Where: any ** Near: any [tst 123] [print "ok"] | |
BrianH 28-May-2009 [14510] | Yeah, that makes sense. Btw, option 2 has been mostly implemented since alpha 38, which came out in January. |
Dockimbel 28-May-2009 [14511] | So the silently ignored typo issue still exists, but would be much less frequent than I feared. |
BrianH 28-May-2009 [14512] | Part of the trick here is that you have to balance the benefits of error generation versus the overhead of error handling. We've been careful to make a lot of code that used to generate errors in R2 just work in R3. If there is a good rationale for "just working" that is. |
Dockimbel 28-May-2009 [14513x2] | Is such move really going toward the PITL where R3 is supposed to bring us? It sounds more like going in the PITS way, making throw-away code even eaiser to write. Maybe I'm just not understanding well what your were saying. |
I agree on the benefits of treating unset! as noops in such cases : ANY [( )] == none ANY [( ) 1] == 1 It's usefull and is consistent with the way COMPOSE treats ( ). But I still think that's some way of getting unset! values may lead to undetected errors like in : >> test: func [a] [print a exit] >> if any [test 123] [print "ok"] 123 == none >> result: test 1 1 ** Script error: result: needs a value I understand why you were asking for such change, but it's hard to know if it won't cause more trouble than gain. | |
BrianH 28-May-2009 [14515x4] | What I'm saying is that sometimes this kind of thing is not an error. The question is whether it is an error more often than not, and if the error is critical enough to justify the error handling code that comes from generating the error. Take the ordinals, for example. We decided to redefine out-of-bounds for the ordinals as not-an-error. It now means return-none, where none is the possibly OK non-data that can be handled with low overhead. |
Keep in mind that people already use ALL and ANY for error handling, and that these functions are lower-overhead than TRY and ATTEMPT. We are trying to reserve generation of errors for those cases where the situation is usually or always an error. If it is intended and sensible behavior in some cases, we tend to be less stringent. | |
I'm not saying that unset! values in an ANY or ALL is one of those cases where there would be benefits, just that it might be. Benefits like being able to use functions like PRINT in ANY or ALL without having to do tricks like (print 'hello true). If errors would be more common than beneficial code, then generate errors. | |
ANY and ALL are used as control structures too. If () was defined as a noop, I would use it that way on purpose. If not, I wouldn't. | |
Dockimbel 28-May-2009 [14519] | It's hard to say in advance if it will do more harm than good. Unset! values can be generated from various semantic rules, I think it's quite touchy to consider that all these cases are equivalent without exhaustively listing all ways to get unset! values and see one by one if the proposed change would impact it in a positive or negative way. |
BrianH 28-May-2009 [14520] | Not a bad idea, at least for the built-in functions. In my experience, the main use for PRINT in ANY or ALL is debug statements. Most of those go away now that we have ASSERT. We didn't have ASSERT in January. |
Dockimbel 28-May-2009 [14521x2] | Btw (digressing a litlle), I've always found inelegant the way unset! was used by PRINT or other console-oriented functions to avoid returning a value. I'm maybe too purist, but I would have expected PRINT to return the passed argument (making PROBE unnecessary). Other solutions for making functions (native or user-defined) more console-friendly could have been choosed (not having consequences on language's deep semantics), like adding a special flag in the spec block! (as 'save or 'throw). |
choosed = chosen | |
BrianH 28-May-2009 [14523] | I really don't mind having some functions return no-value. The interesting decision to be made on a case-by-case basis whether no-value is an optional return or all the time, and whether no-value is generally an error when used, or not. #[none!] is the no-value that is generally usable as a value, or at least not an error most of the time. #[unset!] is th no-value that really is not a value, and most functions treat it as an error, but not all. |
Dockimbel 28-May-2009 [14524] | I understand unset! values as an exception case where there's no value to work with. As such, IMHO, it should be treated as an error as much as possible. We should stick to the principle of least surprise. It wouldn't hurt if R3 unset! values were treated more consistently. But this is a deep topic, I remember that Ladislav had some interesting propositions about unset! (like, IIRC, removing it from user's eyes and keeping it internal only). While browsing about that, I've found a few interesting links : http://www.rebol.net/cgi-bin/r3blog.r?view=0100 http://www.fm.tul.cz/~ladislav/rebol/rep.html#section-18 |
BrianH 28-May-2009 [14525] | Bug #564 and option 2 were the result of the last time (January) we decided on a consistent treatment of unset! values: - As an error in value contexts, like assignment, function parameters that don't explicitly support it. - As a noop in control contexts, where the value would normally be thrown away, like DO blocks. ANY and ALL were added to this group. |
Maxim 28-May-2009 [14526x2] | funny, I hadn't realised that do blocks already ignore unset values... obviously. |
so it makes sense with any and all too. | |
BrianH 28-May-2009 [14528x5] | We get a different answer every time we have this discussion :( |
Yeah, and it doesn'tt make sense to ignore unset! with REDUCE because that is a value context. With CONSTRUCT it is treated as no-value and not inserted. Both of these are the right choice in their respective cases. | |
The main difference between ANY and DO, aside from ANY stopping early, is that ANY has a default value: none. Having a default value means that no-value is acceptable, so it returns the acceptable no-value. DO doesn't have a default value, so if the last expression generates no-value, that is passed along. That was the rationale for #564 and option 2, at least. | |
I'm actually OK with either option 2 or 3, but there are tradeoffs to either. Which reminds me: Which built-in functions in R3 return unset! values? I can only think of PRINT and PRIN, off the top of my head. WRITE returns a value in R3. Even ASSERT returns true. | |
I just remembered to check the behavior of the other *conditional* control functions: IF, UNLESS, EITHER and CASE. They all treat #[unset!] like option 3, as an error. I guess option 3 is the most consistent. | |
Steeve 28-May-2009 [14533x3] | Yeah, using the last A55, i got better perfs with my virtual block scheme (bug on files corrected). On my small Celeron, i can do now: - 25000 read per sec. - 20000 append/update per sec quite good |
(doing my test with recycle/ballast activated, so that the memory used stay low, arround 3500 Mb. The test file containing 500000 records) | |
Oups !!! not 3500 Mb, but 3,5 Mb | |
Pekr 28-May-2009 [14536] | 3.5MB :-) |
Steeve 28-May-2009 [14537] | yes bytes not bits :) |
Pekr 28-May-2009 [14538] | Steeve - what is the speed compared to R2? |
Steeve 28-May-2009 [14539] | don't know |
older newer | first last |