World: r3wp
[!REBOL3 Extensions] REBOL 3 Extensions discussions
older newer | first last |
Kaj 22-Dec-2010 [1965] | When I split the cURL binding in two contexts, it works, so it seems to be some object limit |
Andreas 22-Dec-2010 [1966x3] | Very peculiar. |
When I export a context wrapping the above 20 cmds, it still works. | |
export cmds: context [cmd01: command [] cmd02: ...] | |
Kaj 22-Dec-2010 [1969x2] | Then please give them some more work to do |
It also bombs out for me when the fifteenth context slot is such an empty command | |
Andreas 22-Dec-2010 [1971x2] | Makes no difference even if I add 3 parameters to each of them. |
Let me try with 10 parameters each. | |
Kaj 22-Dec-2010 [1973] | It sure is a strange thing :-) |
Andreas 22-Dec-2010 [1974x3] | Most peculiar, yes. |
Nope, 20 cmds with 10 params each works as well. | |
Maybe something to do with the length of the init block? | |
Kaj 22-Dec-2010 [1977x2] | OK, let me upload the cURL binding source for you |
I tried shortening the init block, but it didn't help | |
Kaj 24-Dec-2010 [1979] | An error return code is defined for extensions, but it's not used anywhere in the host kit or documentation, so we don't know how to use it |
Kaj 25-Dec-2010 [1980] | There's also a SET_EXT_ERROR macro, but also undocumented, and it only allows setting an unknown number |
Oldes 26-Dec-2010 [1981] | I'm experimenting with image! as a command agrument and found this strange behaviour: I have: img-echo: command [img [image!] ] In RX_Call I use just: return RXR_VALUE; And then when I call the img-echo I get image, but with index at the tail so it looks like: >> i: img-echo img == make image! [50x20 #{ }] >> index? i == 1001 Is this normal? How I can set the index on the C side? |
Oldes 27-Dec-2010 [1982] | I've found solution for my answer related to warning: ../R3A110/src/include/reb-config.h:107: warning: ignoring #pragma warning To remove this warning, use this compiler option: -Wno-unknown-pragmas |
Kaj 27-Dec-2010 [1983x4] | Image index at tail sounds like a bug |
This should set it at the head: | |
RXA_INDEX(arguments, 1) = 0; | |
But it should already be at that value | |
Oldes 27-Dec-2010 [1987x5] | I've located where is the problem.. it's returning the image at the tail if the command is used in exported context! |
Correction... it returns image index at tail when there is any exported context.. the command can be out of the context. | |
http://issue.cc/r3/1809 | |
btw... I was trying to use: RXA_INDEX(frm, 1) = 0; but in my complex extension I was even able to crash REBOL. But I'm not able to simplify it. The sample.c included with the bug report must be enough, it clearly shows that there is something wrong. | |
It's also strange that it returns correct index before I eval the exported context. | |
BrianH 27-Dec-2010 [1992] | I added that last sentence to the ticket, as it might help diagnose the problem. |
Kaj 30-Dec-2010 [1993] | The callbacks documentation is incomplete, and refers to the host-ext-test.c file for examples, but this isn't in the current host kit |
Kaj 31-Dec-2010 [1994x2] | RL_Protect_GC protects unreferenced series from disappearing, but does it also protect them from being moved? |
If not, how can an extension be sure that a pointer to a series is still valid? | |
BrianH 31-Dec-2010 [1996] | I don't think the REBOL GC is copying or compacting. Series are only moved when they are expanded (a reallocation) so if you don't want it to move, preallocate the length you want. |
Kaj 31-Dec-2010 [1997x8] | OK, I gathered that it must work like that if it is to be stable now. But I wonder if it won't get complicated by tasking |
I saw a warning somewhere in the documentation that series can be moved, but maybe that is indeed limited to their own isolated memory management | |
It would explain some of REBOL's high memory usage, because it it doesn't do compacting, there can be a lot of unusable, fragmented memory | |
if it | |
I don't understand, though, how the RL_SET_CHAR and RL_SET_VALUE functions could extend a series when necessary without ever moving it | |
There must be a guarantee that the description data that is pointed to will stay immobile, while the actual data does get moved | |
REBOL must have a global series descriptors registry, much like the words registry | |
It must be only the references to descriptors that get moved when in blocks | |
Oldes 17-Jan-2011 [2005x3] | I would like to make a dialect for making extensions... so far I parsed spec for MagickWand and PixelWand API - https://github.com/Oldes/R3-extension-iMagick But I have a question... in some cases, like in this one: MagickGetImageChannelRange: [ "Gets the range for one or more image channels" wand "MagickWand *" "the magick wand." channel "ChannelType" "the image channel(s)." minima "double *" {The minimum pixel value for the specified channel(s).} maxima "double *" {The maximum pixel value for the specified channel(s).} return: "MagickBooleanType" ] The command should return block [minima maxima] or FALSE... any idea how to specify it in the dialect? |
It's quite clear, what it should return, when you see it in REBOL like form, but it's quite difficult to do such a decision when parsing the spec.. that's also the main reason, why I decided to work on human readable dialect. (I was trying to generate the extension directly, it's possible, but it seems to be hard to maintain.) | |
Just to make clear what's the issue.. for above example, the extension command should looks like: MagickGetImageChannelRange: command [ "Gets the range for one or more image channels" wand [handle!] "the magick wand." channel [integer!] "the image channel(s)." ] The minima, maxima are just pointers to values which are used to return the result, which I must convert to REBOL block. | |
Oldes 25-Jan-2011 [2008x5] | I'm using this piece of code to get pointer to binary argument: char *srcData; REBSER *ser = RXA_SERIES(frm, 1); srcLen = - RL_GET_STRING(ser, 0, (void **) &srcData); But also must do this: srcData+=RXA_INDEX(frm,1); To fix the pointer to correct position if the source binary index is > 0. Is this a bug or is it normal? Should it be reported in CC? |
OH... forget it... the correct way is using: REBSER *ser = RXA_SERIES(frm, 1); char *srcData = RL_SERIES(ser, RXI_SER_DATA); u32 srcLen = RL_SERIES(ser, RXI_SER_SIZE); | |
Correction... the right result is: srcData = RL_SERIES(ser, RXI_SER_DATA) + RXA_INDEX(frm,1); srcLen = RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) - RXA_INDEX(frm,1) -1; so I don't know what is better. | |
the recapitulation: http://issue.cc/r3/1836 | |
Also added comment to related bug http://curecode.org/rebol3/ticket.rsp?id=1816&cursor=21#comments | |
Maxim 25-Jan-2011 [2013x2] | Oldes, AFAIK its normal... in C we always have access to the full string. we use RL_SERIES to figure out the portion of the string which is used by a specific Series reference. so basically if you call: a: [1 2 3] b: next a and use A or B in the command, you get the same string (logically, not physically), but with only the RL_SERIES and RXA_INDEX() which are set to different values. |
I'd say your option 2) is the more "correct" method. though both are OK. basically, one counts from the end, the other from the start. | |
older newer | first last |