World: r4wp
[#Red] Red language group
older newer | first last |
DocKimbel 5-Jul-2012 [616] | Right, yes, that's a feature I was planning to have in Red (didn't know that it was called formally "automatic delegation"). |
GiuseppeC 5-Jul-2012 [617] | Doc, someone else told me (as far I remember BrianH). I could be wrong ! |
DocKimbel 5-Jul-2012 [618] | A good and non-ambiguous syntax would be needed for that though. |
Kaj 5-Jul-2012 [619] | I thought about implementing some basic series functions in Red/System, but they would be primitive and hardly used once the Red memory manager is available. There could still be a place for them in low level coding, but right now it doesn't justify the effort for me |
BrianH 5-Jul-2012 [620] | Giuseppe, those are called properties. The getter/setter functions you often find in GUIs are basically the same thing, but properties hide that in regular assignment syntax. We don't need getter properties in REBOL-like languages because we don't use parentheses to call functions, but setter functions appearing to be assignment statements might appeal to some. I've had a lot of experience with properties in languages like Delphi; most of the popular languages that currently have property support, either in syntax or as a convention, are derived from Delphi. It makes code a little easier to write, and a lot harder to debug. The main advantage to implementing them in Red or R3 would be to make it easier to interoperate with .NET or COM objects. Automatic delegation is something else. With automatic delegation, you automatically forward a method call from one object to another, just by declaring it as such. That doesn't really work in REBOL-style direct-bound functions because we don't have an implicit self parameter (we have self, but it's not a parameter). Red would need to have a completely different function binding model for that kind of thing to work; which it would likely have anyways, due to it being compiled rather than interpreted. |
GiuseppeC 7-Jul-2012 [621] | BrianH, thanks for saving me from my ignorance. |
Rebolek 10-Jul-2012 [622] | If I create struct! inside function and return pointer to that struct (as I cannot return struct), how can I get the struct from that pointer? |
DocKimbel 10-Jul-2012 [623] | Structs are always passed and manipulated by reference. You should be able to return struct! (unless there's a bug). |
Rebolek 10-Jul-2012 [624] | This code: return-struct: func [ return: [struct!] ][ s: declare struct! [ a [integer!] ] s/a: 1 s ] returns error in compilation: invalid definition for function return-struct: [struct!] |
DocKimbel 10-Jul-2012 [625x2] | [struct!] is missing its spec block with members definition. |
should be: func [ return: [struct! [a [integer!]]] ] | |
Rebolek 10-Jul-2012 [627] | ah, thanks! |
Kaj 10-Jul-2012 [628] | An ALIAS is handy for such cases |
Rebolek 11-Jul-2012 [629] | If I run this code s: declare struct! [ f [float!] ] s/f: 12345678.9 p: as byte-ptr! s v: p/value w: 256 * as integer! p/value x: 256 * as integer! v print [x ".." w] I get this result: 52480..4194304 Why the difference? Shouldn't W and X be same as V is same as P/VALUE? |
Pekr 11-Jul-2012 [630] | Leaving for the heavy metal festival. Hopefully on my return on monday, there will be some refreshed news towards when Red development will resume :-) |
Henrik 11-Jul-2012 [631] | Leaving for the heavy metal festival. - It's good to see people celebrating parts of the periodic table of elements. Oh, maybe it means something else... :-) |
PeterWood 11-Jul-2012 [632] | Why the difference? Shouldn't W and X be same as V is same as P/VALUE? I checekd that v = p/value so it would appear to be the type casting that is the problem. I checekd the spec and casting a byte! to and integer! should be okay. So it seems like it is a bug. |
Arnold 11-Jul-2012 [633] | When will they put beer on the periodic table of elements? Hopefully after Red is finished? |
Rebolek 11-Jul-2012 [634] | f: func [ val [integer!] return: [struct! [value [integer!]]] /local s ][ s: declare struct! [value [integer!]] s/value: val s ] s1: f 1 print ["s1/value:" s1/value lf] s2: f 10 print ["s1/value:" s1/value lf] ; --- outputs: C:\code\Red\red-system\builds>test s1/value:1 s1/value:10 After setting S2 value, S1 is changed. Why? Is it a bug? |
Kaj 11-Jul-2012 [635] | Looks like it. Odd |
PeterWood 11-Jul-2012 [636x2] | I don't think it's a bug. s is a local (static) variable in function 'f. f returns a reference to s. So if you change the contants of s/value, all references to s will now refer to its new value. |
I added prints of s1 and s2 to your program; this is the output : s1 9348 s2 9348 | |
Rebolek 11-Jul-2012 [638] | So how I can return new struct! each time? |
PeterWood 11-Jul-2012 [639x3] | Only by declaring the struct! in your main program and passing it (its reference) as an arugment: f: func [ val [integer!] s [struct! [value [integer!]]] ][ s/value: val ] |
Well that's the only way that I've found so far. | |
Once the Red memory manager is available it may well be possible to use it to allocate struct! in a function but then there is the problem of how to release the memory later. From a memory mangement point of view, it seems easiest not to allocate variables inside functions to be returned to the calling program/function. | |
Rebolek 11-Jul-2012 [642] | ok, thanks |
Kaj 11-Jul-2012 [643x2] | Oh right, the pointer is returned from the function, not the value |
There's no problem in allocating memory to return from a function, but you have to use ALLOCATE and later FREE it | |
Rebolek 11-Jul-2012 [645] | Ok, so this version does what I expected :) f: func [ val [integer!] return: [struct! [value [integer!]]] /local s ][ s: declare struct! [value [integer!]] t: allocate size? s s/value: val t: copy-memory t as byte-ptr! s size? s as struct! [value [integer!]] t ] s1: f 1 print ["s1/value:" s1/value lf] ; == 1 s2: f 10 print ["s1/value:" s1/value lf] ; == 1 |
Kaj 11-Jul-2012 [646x5] | You don't have to declare an intermediate struct and copy it |
t: as struct! [value [integer!]] allocate size? s | |
t/value: val | |
t | |
You should check the allocation for being a null pointer, though | |
Rebolek 11-Jul-2012 [651] | how that can happen? |
Kaj 11-Jul-2012 [652x3] | If you don't get the memory from the operating system |
The form-* functions in the C library binding do pretty much that: | |
http://red.esperconsultancy.nl/Red-C-library/artifact/a1a55e070454c421657185b1d9d09f480d6c5587 | |
Rebolek 12-Jul-2012 [655] | Another question :) Is there any easy way to convert integer! to float! ? I wrote something for float! to integer!, but with integer! to float! I'm bit lost. |
Ladislav 12-Jul-2012 [656x3] | Another question :) Is there any easy way to convert integer! to float! ? I wrote something for float! to integer!, but with integer! to float! I'm bit lost. - see http://www.fm.tul.cz/~ladislav/rebol/library-utils.r |
The approach is as follows: 1) convert integer to double (=decimal!) 2) convert double to float | |
aha, sorry, this is a Red group... | |
Rebolek 12-Jul-2012 [659x2] | yes, I'm looking for Red/System solution. |
Why does this code throw *** Runtime Error 11: float stack check ? i: 0 f: 0.0 p: declare pointer! [float!] arr: allocate 100 while [i < 10][ p: as pointer! [float!] arr + (i * 8) p/value: f f: f + 0.1 i: i + 1 ] | |
Kaj 12-Jul-2012 [661x5] | Sounds like a bug, although the program is overly complex |
i: 0 f: 0.0 arr: as pointer! [float!] allocate 10 * size? float! while [i < 10][ p/i/value: f f: f + 0.1 i: i + 1 ] | |
That should work, and be more secure | |
arr/i/value: f | |
Oh, with path notation, you need to adjust the loop to start counting the index from 1 | |
older newer | first last |