Re: Lepton EDA 1.9.14 announce and misc questions

[Matt Wette <matt.wette@gmail.com>]

On 4/20/21 4:36 PM, Vladimir Zhbanov wrote:
> Hi Matt,
>
> On Tue, Apr 20, 2021 at 06:46:27AM -0700, Matt Wette wrote:
>>
>> On 4/20/21 5:47 AM, Matt Wette wrote:
>>>
>>> On 4/20/21 2:29 AM, Vladimir Zhbanov wrote:
>>>> Hi Guile users and devs,
>>>>
>>>> I'm the current maintainer of Lepton EDA suite, an about five year
>>>> old fork of geda-gaf with accent to moving more functionality to
>>>> Scheme code.  I'm not sure if it is acceptable to advertise it
>>>> here, please let me know if not.  I just know several Guix
>>>> packagers are reading this mailing list and would like to announce
>>>> a new version of Lepton, 1.9.14 has been released on April, 7:
>>>>
>>>> https://github.com/lepton-eda/lepton-eda/releases/tag/1.9.14-20210407
>>>>
>>>>
>>> Sweet.  Thanks for posting this.   I will take a look at your problem.
>>> It'll require digging into the eda_..._dirs function.
>>>
>>>
>>>
>> The following should work as a complete program on a system w/ glib.
>> You need to first convert the result to a bytevector and then access the
>> elements (pointers) one at a time.  Note that we don't know how big the
>> array returned from the C function is.  I pick an oversized value of 100.
>>
>> (use-modules (system foreign))
>> (use-modules (rnrs bytevectors))
>>
>> (define glib (dynamic-link "libglib-2.0"))
>>
>> (define g-get-system-data-dirs
>>    (let ((f (pointer->procedure
>>          '* (dynamic-func "g_get_system_data_dirs" glib) (list)))
>>      (bv-pointer-ref (cond
>>               ((= (sizeof '*) 8) bytevector-u64-native-ref )
>>               ((= (sizeof '*) 4) bytevector-u32-native-ref )
>>               (else (error "hmmm"))))
>>      (BIG 100))
>>      (lambda ()
>>        (let* ((r (f))
>>           (p (pointer->bytevector r (* BIG (sizeof '*)))))
>>          (let loop ((ix 0))
>>            (let* ((ad (bv-pointer-ref p ix))
>>               (sp (make-pointer ad)))
>>          (if (equal? %null-pointer sp)
>>              '()
>>              (cons (pointer->string sp) (loop (+ ix (sizeof '*)))))))))))
>>
>> (simple-format #t "~S" (g-get-system-data-dirs))
> Thank you for your replies!
>
> Probably, I missed something here, so I'll try to elaborate a bit
> on my initial question.  The function eda_get_system_data_dirs()
> mentioned in my first message has the same type, is defined the
> same way using dynamic-func though in liblepton instead of glib,
> and works on mostly the same array as glib's
> g_get_system_data_dirs().  The function I've shown works well and
> outputs the same results as yours.  It simply uses a bit more
> upper level interface, IIUC.  So the first question is: I wonder,
> if using bytevectors directly adds something here?
>
> Another issue is a little more confusing for me.  I read in
> several places that even on the same system different compilators,
> say gcc and g++, may use different alignment even for basic C
> types like, say, double.  What will they do on different platforms
> then?  May it be that (alignof '*) will be twice greater than
> (sizeof '*)?  In such a case using multiplied sizeof of pointer
> for searching the location of a pointer in memory would be just
> dangerous.  I used sizeof in the first version of my code but
> started to doubt if it is correct and how portable it is.
>
> Thanks,
>    Vladimir
>
Hey.   I used the glib routine because it returns the same form,
if I read correctly.   The return value is a pointer to a sequence
of (C) pointers.  On my machine they are 8 bytes each.  So, if
the function is returning three strings, say, the first 8 bytes will
be a pointer to the first string and last 8 bytes (of a total of 32
= 4 * 8) will be zero.  You need to access the three 8-byte
pointer values as numbers and convert to guile pointers to
access the strings.   I don't see a way around that.

I don't see this being a problem with gcc vs g++.   Maybe in
structs with mixed types, but not here, IMO.

Matt