From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Wette Newsgroups: gmane.lisp.guile.user Subject: Re: Lepton EDA 1.9.14 announce and misc questions Date: Tue, 20 Apr 2021 17:34:59 -0700 Message-ID: References: <510bfaf9-aa4f-50cd-deb3-7a15247a9bfa@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33961"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Apr 21 02:35:50 2021 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZ0qM-0008iD-AE for guile-user@m.gmane-mx.org; Wed, 21 Apr 2021 02:35:50 +0200 Original-Received: from localhost ([::1]:59492 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZ0qL-0001mG-7X for guile-user@m.gmane-mx.org; Tue, 20 Apr 2021 20:35:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZ0pi-0001m1-IQ for guile-user@gnu.org; Tue, 20 Apr 2021 20:35:12 -0400 Original-Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:41787) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZ0pb-0005FS-1b for guile-user@gnu.org; Tue, 20 Apr 2021 20:35:10 -0400 Original-Received: by mail-pg1-x52b.google.com with SMTP id f29so28059315pgm.8 for ; Tue, 20 Apr 2021 17:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=TDUOYmNKQwwIaiS+a989C5Q6RT9/Nfn6Zwedgrnt/t0=; b=ijCcuMTDzXXYyxz7U1FWCmhc1fr2G8wMZkcaVsICIDQeF/K+hg5TOZYuUhvjn42oAT 1Y2MbjPpxcWZ1py7/5ZSWNhS1FcK9tI83AHDXDlCzYD74X4z9fXVdyAocmuLWXTN87nj zj/G7nQ8K+2Nlbi2zTNLjXAEfUz61FOj4YJ7y4biMqI9c+Nbid/udZd0MnBesvdQUXOI FUx6Qa4DtuccMOCUuWw5v5i58zD5BTeMW0lMHjWiNP7LG6d0fGMGfBEjE9WX1iM5jRhG 2qTzw3FAVlF9S69+kBG4bNTyuBwC2QS1uwoaUrSll5m0Fc3FWD3C5bkMOuMQLKxdLsAU 7qfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=TDUOYmNKQwwIaiS+a989C5Q6RT9/Nfn6Zwedgrnt/t0=; b=i+FiW9QKHpg2KWrEfY6h8B9udEgGy+QKegsO8TETLm1KwouBJr9or0NaTYZ/l0QgRY iiKUV9QrmAUX8AntEf6mhP7o/a/bwzoLbUrsaVCqkdTI7C1WF9fdaN3JPtjYzXZLjf7P CF+wZy6ryWWT3uz0aUyi6slDycuB8Oy8PhKKtZNTwHgTa4tPIWIssexmXHWbI9W033Uu p4BZH0WEb+yK+FFAkUkMQFFYbpwvONgPEV7KyvqTAfZnzjvyK8gzhUpDBfo+OFTwuI67 T6DLNg9vc975tShagocMkOEF/LGF9T5FdiWFsW8CSITD9VC/QUMbY7ZeBGzzMrgTjsah I6+w== X-Gm-Message-State: AOAM530PveKSo8ZcaPzB/awRZTzqDD/UoJWxzkW9nQ6dZMLSHX3ufbW0 SMJEOmmF6uvS71kvBIHZcK9k4Ha2ZPk= X-Google-Smtp-Source: ABdhPJwEsoU3aWCMeBbX0hWJ+OQ4tsaa4VtXGyPYlC2HokKPyhoi9obtHKJSwt3FU9z+ng3QUMCgkg== X-Received: by 2002:a62:6497:0:b029:220:d96a:8a79 with SMTP id y145-20020a6264970000b0290220d96a8a79mr27181570pfb.23.1618965301199; Tue, 20 Apr 2021 17:35:01 -0700 (PDT) Original-Received: from [192.168.2.126] (64-52-176-132.championbroadband.com. [64.52.176.132]) by smtp.gmail.com with ESMTPSA id h24sm235832pjv.50.2021.04.20.17.35.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 17:35:00 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=matt.wette@gmail.com; helo=mail-pg1-x52b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17429 Archived-At: 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