delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/08/02/21:44:03

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1470188552; bh=CJiWzxxfgQiOgataWriMxDmpN+4u2rHnh0pQsWiKQkI=; h=Subject:From:In-Reply-To:Date:References:To:From:Subject; b=AQCcamldOcw+O72nmnWRdDFIQivtexHR5x8su4eqxPlN4Ww5PCq0GElVJDZAkvX4Gf7sY7+kSojjg16Z+W53zKw+Ntc4n77sudGLJOw0ZM3pz0qp905uZBODbYW+CPKogovo3y1OH+FNWSMRIBy+f6V0vwzqW/ik+vvYlbxY1DAfPOiuE5Ir5H0t/rF8uIc1r/J5HbLJmR7fhQ2KFm5GPJIkV55qAKDCR7EqQ5vdUKXr8FZNuIFjHU/fO9RC/r/hlNz/Jx6q5H13d8ytOgQOs65HcTCSunIK8OOXEebqS+gJJPsaiTPZuK3hBj9ZBTXTizfQAGerEMZ4KY9XXMVCrA==
X-Yahoo-Newman-Id: 267948 DOT 73099 DOT bm AT smtp114 DOT sbc DOT mail DOT gq1 DOT yahoo DOT com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: QEp0YnEVM1mQNAG33wmYazCTut3H98_zc2SsnNW3UKet4Ve
Ur_rykP0nLdJiJdYCdX2qntIozrKw2st8SqCKwX6cAiFg.wTsM36vaQSxeT1
629jPWO81CP4gYhrvYJO3jcIubzJ3cRRe45KNugaCU7OI2fWYqB7lBQk.QO_
.4bt9FZ4o5MXVMgQV.AhwVQ8rJaYLWQKRjZwMmeJzJYsFOagXgDoXy7EABbJ
p1hMpM2LaW9NY.PkiagIN9EnjNIHGH9P2NOslhT9vn_MT8.ZabbxnYpYcH6f
yz2R6kJfrzh5DvHRs35ouVdDPqWEFMBSsWAtzkDTdyErPx8qJzoW_nNvhj57
GqtcHcoBSDnm_rjMuFNiIZEIx7sx9LbnyCkIarN9SGfVrh_mzdcUIq9sxich
KQ0.yXGPMX1LZ1Gnz48wpjTyt23XWxPaUuaf0ZUWe.808CdYrLF.xgFenRe0
H1kwED_4hBO1KvxK9BmrWCkJEvrNnEqGSIbvQTftS1PyEWNdyVWd1Zs6APjN
rhbiyRYJfGvUPPiUabBfA8_vXchRC1KT.2MOYDp0V2lj40FzwFnDmE3cBybM
k1E4-
X-Yahoo-SMTP: b8jVkbOswBAqZ4BhECp7nxPJUfTGEnEGv_G4qgQeZMeAbA--
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [geda-user] Plans for gEDA/gaf (was: [OT] ngspice integration in KiCad)
From: "Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
In-Reply-To: <alpine.DEB.2.11.1608030034050.9981@nimbus>
Date: Tue, 2 Aug 2016 18:42:30 -0700
Message-Id: <9D48E76E-9D22-4708-A5E3-3AFF976C697B@sbcglobal.net>
References: <CANqhZFwC48g07MUY411a20C5oipkmmkzUimhz8OgvL2Thi-yDg AT mail DOT gmail DOT com> <20160722171754 DOT GB17595 AT localhost DOT localdomain> <CAM2RGhRjABmejtuSz1PbGFFF+EHhznGGTODoh0bu2y4FJM=Cbw AT mail DOT gmail DOT com> <20160723065723 DOT GC17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 00 DOT 1607231009290 DOT 7286 AT igor2priv> <20160723092248 DOT GF17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607231423480 DOT 2224 AT nimbus> <20160724053502 DOT GM17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607271434200 DOT 1841 AT nimbus> <9719FF2C-AC85-4824-89E9-447216E7FA65 AT sbcglobal DOT net> <alpine DOT DEB DOT 2 DOT 11 DOT 1607301258260 DOT 1409 AT nimbus> <939E39F7-B4DA-4B56-A640-C7E6E4ECF955 AT sbcglobal DOT net> <alpine DOT DEB DOT 2 DOT 11 DOT 1608021426490 DOT 1398 AT nimbus> <CAOP4iL2MsJG+U45C83zWevHcWwLoJAnYa9uYzM0fqoXvxg66qg AT mail DOT gmail DOT com> <9ED612EF-E3F5-48CC-8FB3-B67CA7DEE432 AT noqsi DOT com> <CAOP4iL1TcA4nzvCBJuFQ7GaOA-Owub2ikedXOvrcWipr9=buxA AT mail DOT gmail DOT com> <9D554144-D41A-463F-955F-68227BC3D167 AT noqsi DOT com> <CAOP4iL2mhxmbjkkLKTgbtME-VEmAFwQCAQGc412KKNfAdzA1og AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1608030034050 DOT 9981 AT nimbus>
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
X-Mailer: Apple Mail (2.3124)
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u731ga74017194
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> On Aug 2, 2016, at 3:40 PM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
> 
> Edward Hennessy:
>> Roland Lutz:
>> > The core library should not know about GObjects in any way.  Of > course, it would be possible to create a GObject wrapper for the core > library which could be used for creating language bindings.
>> 
>> Sure, but its extra work to create all the wrapper objects. And wrapping RIAA with reference counting is a mess.
> 
> RIAA and reference counting both don't make sense on this level.  We're talking about a simple C library which defines some structs and declares functions to work on them.  If you want a nice C++ class which allocates and frees e.g. a revision RIAA-like, just write it.  Having this kind of logic in the library API just makes things unnecessarily complicated.

If the system has a heap, and the code uses pointers, then something must be used. Wrapping plain pointers with reference counting, RAII, or garbage collection is a mess.

>> > The library would use a value-oriented approach: the properties of a > schematic object are only defined in respect to a given revision.  If > an application needed property change hooks, it could execute them > itself from the command which replaces its current revision with a new > one.
>> 
>> Sure, the wrapper objects from above could provide property change notification. It’s extra work to manage this layer. And when scripts modify the “libcore” POD objects, it might not even be capable of determining a property change occurred.
> 
> There's no such thing as a "change" in a value-oriented approach.  That's intentional because having a place-oriented approach would force that model on all code parts, while it's easy the other way around.
> 
> Detecting a property change is always possible because once you finalize a revision, no code part can change it (except by poking directly into memory).  When a script creates a modified copy of a revision and passes it back to the main application, it can query for differences between the two revisions and act accordingly.

You are referring to programming with immutable objects?

If you are referring to immutable objects, then my take:

- they make command line and multi-threaded applications awesome
- they make GUI programming a giant mess

>> > I'm not sure what's your point here.  Do you want to facilitate using > gschem widgets in other GTK applications?  The actual Cairo rendering > code may be useful to non-GTK or even non-interactive applications.
>> 
>> Exactly.
> 
> Exactly what?  libgedacairo is already available as a library which could, in theory, be used in other applications.  The only problem I see right now is that it depends on the internal libgeda object representation which doesn't make much sense for applications outside the main geda-gaf repository.

Exactly refers to your question: "Do you want to facilitate using gschem widgets in other GTK applications?”

>> What is the downside of using Vala?
> 
> Potential contributors would have to learn a new programming language.
> 
>> What can go wrong and what is the chance of it going wrong?
> 
> The single developer knowing Vala could leave the project.  Mono could be bought by Microsoft and discontinued.

What is the upside to using Vala?

In regards to C#:
- Xamarin was already bought by Microsoft.
- Miguel de Icaza is now a Microsoft employee.
- Compilers and framework are being open sourced under the MIT license.

Some controversy and questions of Microsoft’s intent exist, but I’ll let the reader research on their own — it’s all speculative.

>> I disagree with you on the “libcore” responsibilities, because small amounts of additional code at this level can significantly reduce the amount of work needed to implement the GUI level.
> 
> There's a difference between crafting a good API and merging application specifics into a library.  What if a program should use the core library but isn't written in C++, or doesn't use GLib?
> 
>> > Why would the core library need to know about scripting?
>> 
>> For example, libgeda has the capability of executing a script to load a component.
> 
> The core library wouldn't have to know about scripting in order to allow that; providing a hook for adding custom library sources would be sufficient.

You missed my point of dependency inversion and its BFF: dependency injection.

You are not selling this technical direction:

- No memory management (more work for the GUI programmer)
- Need to write wrapper objects for "libcore” (more work for the GUI programmer)
- No property change notification (more work for the GUI programmer)
- No automatic bindings (more work for the GUI programmer)
- Not using a more productive language (more work for the GUI programmer)
- Might decide to rewrite GUI in a different language, later (GUI programmer’s work thrown away)

Come on, just add something to make the GUI programmer’s job easier...

Ed

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019