|
Post by tsh73 on Sept 9, 2021 14:30:42 GMT -5
Ability to pass array as a pointer to a sub/function would be useful as well These guys in C world live with it, so we can use it too.
As for passing arrays to/from dlls - how about making fast (LB native) packing LB array into C-friendly array in memory, passing that memory to DLL, and unpacking it back? With possible type selecting (byte int double).
|
|
|
Post by Carl Gundel on Sept 9, 2021 16:23:43 GMT -5
Ability to pass array as a pointer to a sub/function would be useful as well These guys in C world live with it, so we can use it too. As for passing arrays to/from dlls - how about making fast (LB native) packing LB array into C-friendly array in memory, passing that memory to DLL, and unpacking it back? With possible type selecting (byte int double). I mentioned in a previous reply to this thread about the impracticality of passing a pointer to an array into a function or sub. As for marshaling arrays for DLL calls, that's certainly doable.
|
|
|
Post by Carl Gundel on Sept 9, 2021 16:28:14 GMT -5
In this case, I think there are four options one could implement... 1. Ability for an array to be completely Global (already exists) 2. Ability to pass an array into a Sub/Function; Sub/Function gets a copy of the array on its stack to manipulate and the original is not touched 3. Ability to set up a double-pointer to an array that way if GC moves the array in the VM, the pointer to the array would be updated with the new location of the array and LB's pointer still points to the array pointers location. Of course, we would need to be able to dereference the double-pointer situation to get to wherever the actual array is. 4. Or, if Carl's version of Smalltalk does it, make arrays fixed objects that way the GC will not move them. Just my thoughts on the conversation there... {:0) Brandon Parker As for 2 why do you want to make a copy? As for 3 why do we need to do this when we can simply extend LB to support passing arrays? What value does the pointer (or double pointer) give us? The memory address of an array isn't very useful, unless I misunderstand. Perhaps Smalltalk can freeze the position of the array, but I suspect not unless it is copied into non Smalltalk memory, and in this case it wouldn't be visible to Liberty BASIC unless you copied it back.
|
|
|
Post by Brandon Parker on Sept 10, 2021 14:43:18 GMT -5
I'm not saying I would want/need any of those things. Understanding that arrays are global in nature is enough for me to understand how to utilize them in any manner that I want.
#2 - Would suffice for passing them "ByVal" #3 - If arrays can't be fixed in the VM memory then having a pointer to the array object's pointer should suffice for being able to access it no matter where the GC moves it. Passing arrays to DLL's and such comes to mind with this one.
From what I have briefly read, it does look like Smalltalk provides the ability to create fixed objects so that the GC doesn't move them when it cleans up, but I am just stating what I read.
{:0)
Brandon Parker
|
|
|
Post by Carl Gundel on Sept 10, 2021 15:15:26 GMT -5
I'm not saying I would want/need any of those things. Understanding that arrays are global in nature is enough for me to understand how to utilize them in any manner that I want. #2 - Would suffice for passing them "ByVal" #3 - If arrays can't be fixed in the VM memory then having a pointer to the array object's pointer should suffice for being able to access it no matter where the GC moves it. Passing arrays to DLL's and such comes to mind with this one. From what I have briefly read, it does look like Smalltalk provides the ability to create fixed objects so that the GC doesn't move them when it cleans up, but I am just stating what I read. {:0) Brandon Parker #2 - This makes sense in C but not Smalltalk. Better to pass the array object (which implicitly passes a Smalltalk managed pointer). #3 - Again, this would make sense in C. If you want to pass an array to C, then yes you pass a pointer to a C-ified copy of a Smalltalk array. I'll look into it (the creation of fixed objects), but I'm not sure what that buys us. -Carl
|
|
|
Post by tsh73 on Sept 11, 2021 0:08:51 GMT -5
>>not sure what that buys us. Passing arrays to DLLs?
EDIT Passing arrays to/from DLLs (fast) save/load arrays as a whole in binary form (as unformatted chunk of memory)
|
|
|
Post by Carl Gundel on Sept 11, 2021 9:57:27 GMT -5
>>not sure what that buys us. Passing arrays to DLLs?
EDIT Passing arrays to/from DLLs (fast) save/load arrays as a whole in binary form (as unformatted chunk of memory) Yes, of course, but that's not what I thought he was asking for. I imagined he was asking for a pointer to an array so that it can be operated on in BASIC, not inside a DLL call.
|
|
|
Post by Walt Decker on Sept 11, 2021 11:52:14 GMT -5
Mr. Gundel, I do not see the problem. Given:
A$ = "This is an array of bytes; This is also an object and a collection" B = FN.NoChange(A$) B = FN.WorkOnIt(A$) END
FUNCTION FN.NoChange(B$) 'Receives a pointer to the address of a copy of A$ END FUNCTION
FUNCTION FN.WorkOnIt(BYREF A$) 'Receives a pointer to byte zero of array A$ A$ = "Trunkated Array" END FUNCTION
I really see no difference between
A$(actually a dynamic array of bytes) and DIM B(65)(a fixed array of 66 elements each of which are 4 or 8 bytes in size)
I am no compiler person. I know that blocks of memory move around. But, logically, while a block is referenced the begining address should be locked.
|
|
|
Post by Carl Gundel on Sept 11, 2021 21:08:07 GMT -5
Mr. Gundel, I do not see the problem. Given: A$ = "This is an array of bytes; This is also an object and a collection" B = FN.NoChange(A$) B = FN.WorkOnIt(A$) END FUNCTION FN.NoChange(B$) 'Receives a pointer to the address of a copy of A$ END FUNCTION FUNCTION FN.WorkOnIt(BYREF A$) 'Receives a pointer to byte zero of array A$ A$ = "Trunkated Array" END FUNCTION I really see no difference between A$(actually a dynamic array of bytes) and DIM B(65)(a fixed array of 66 elements each of which are 4 or 8 bytes in size) I am no compiler person. I know that blocks of memory move around. But, logically, while a block is referenced the begining address should be locked. This seems unclear to me, sorry. What problem or problems are we trying to solve? -Carl
|
|
|
Post by sarmednafi on Sept 17, 2021 10:27:42 GMT -5
Hi everyone, I would like to see a good instruction manual with LB5. Thank you, Carl All the best.
Sarmed Nafi
|
|
|
Post by Carl Gundel on Sept 17, 2021 13:04:45 GMT -5
Hi everyone, I would like to see a good instruction manual with LB5. Thank you, Carl All the best. Sarmed Nafi So, I assume you mean that the help file should be expanded? What kinds of additions would you like to see that are not there now?
|
|
david
New Member
Posts: 6
|
Post by david on Sept 17, 2021 19:50:24 GMT -5
Hi everyone, I would like to see a good instruction manual with LB5. Thank you, Carl All the best. Sarmed Nafi So, I assume you mean that the help file should be expanded? What kinds of additions would you like to see that are not there now? When I purchased LB years ago I got a CD with the news letters and Alyces Liberty Basic Companion. Which made it a really good tutorial package. Is that included now a days in the age of digital downloads. If not possibly an electronic copy of your book written a few years ago would be a useful addition.
|
|
|
Post by Rod on Sept 18, 2021 3:51:17 GMT -5
I am looking forwards to having the new syntax explained and seeing how the wigits can be managed. I suspect that is Sarmed's interest as well. The help file format has served us well, no need for too drastic a change.
We should help Stefan get the wiki back on line, that would probably be the easiest way to get a live help resource on line.
|
|
|
Post by Gordon Rahman on Sept 18, 2021 11:02:52 GMT -5
I am looking forwards to having the new syntax explained and seeing how the wigits can be managed. I suspect that is Sarmed's interest as well. The help file format has served us well, no need for too drastic a change. We should help Stefan get the wiki back on line, that would probably be the easiest way to get a live help resource on line. I would like to help. How can I help? Gordon
|
|
rnbw
New Member
Posts: 48
|
Post by rnbw on Sept 20, 2021 6:09:43 GMT -5
I am looking forwards to having the new syntax explained and seeing how the wigits can be managed. I suspect that is Sarmed's interest as well. The help file format has served us well, no need for too drastic a change. We should help Stefan get the wiki back on line, that would probably be the easiest way to get a live help resource on line. I agree with Rod that the syntax of LB5's new commands should be explained asap. Without explanation users are somewhat in the dark and thier code will be subject to unnecessary errors. I think that Carl Cundell will get a lot more help from users if he could make these clarifications. Also important is to identify commands that will no longer be used and what should be used in their place. LB already has a comprehensive help file and a lot of this will be unchanged in LB5. I would like to see this used as the basis of a new help file that could be built up as development progresses, possibly using a colour coding system with new commands etc in say blue and those to be removed in say red.
|
|