Re: [Pan-users] Body pane is wrongly resizing pan's top-level window

[Duncan]

walt posted on Sat, 04 Jul 2015 08:22:37 -0700 as excerpted:

> On Sat, 4 Jul 2015 05:06:46 +0000 (UTC)
> Duncan <address@hidden> wrote:
> 
>> walt posted on Fri, 03 Jul 2015 16:30:42 -0700 as excerpted:
>> 
>> > On close inspection of the cached files I see that the original
>> > article was posted using a news client that was compiled from git
>> > repository source code.
>> 
>> What was that client?  Not pan, was it?  Linux platform?  MS? Something
>> new, perhaps on github, or an older, traditional client,
>> now moved to git for development?
> 
> https://github.com/madcowfred/newsmangler
> 
> It turns out to be pure python with no gui.  Very nerdy indeed.  The
> author tells us that it's no longer maintained and points us to a more
> recent version, also hosted on github, and written in Go.  Go figure.

Interesting, particularly in the timing...

As regulars no doubt know by now I've been a gentooer for over a decade 
now.  While I'm not a gentoo dev, I follow the gentoo-dev list, for among 
other reasons, to get a heads-up on package changes that are likely to 
affect my system.

ATM, there's a thread on gentoo-dev discussing go-based packages, and the 
best way to handle them.  Gentoo's "packages" are called ebuilds.  These 
are basically fancy shell scripts defining specific functions that the 
package mangler handles in a particular order (unpack comes before 
prepare, which is followed by configure, compile, (fake-)install (to 
temporary location), quick-merge (to live filesystem), post-install, in 
that order, with hooks for local-system function hooks available as 
well).  Many, probably most ebuilds, inherit eclasses as well.  These 
eclasses serve as libraries for functions called by many ebuilds.

And the gentoo-dev thread is about setting up a couple go-targeted 
eclasses, to be used in go-based-package ebuilds.

Go-based applications turn out to be an interesting case to package, 
because while they do have libraries, all libs are static-only -- they 
are normally built as part of the application build process and get built 
into the final binary.

So the discussion has been about how to handle these static-only go-based-
libs, particularly when many of them either don't have a formal release 
process, or don't keep sources tarballs around for previous releases, so 
the only way to get them is either to pre-fetch the sources, tarball them 
and put the tarballs on the gentoo mirrors, or do a live-VCS build that 
fetches from git or wherever, and checks out a particular tag or snapshot 
for the build.

The debate is around whether to let go's own go build (or whatever it is) 
process automatically fetch and build everything, thereby repeatedly 
building libs if they are used by more than one package, or whether to 
separately package and build the libs, so they're available at build-time 
for the apps that need them, even tho there's no runtime component as 
they're static-libs only.  Plus all the various details, of course.

And once all that is settled, the agreed approach will be setup in the go-
targeted eclasses, which can then be used by whatever go-based ebuilds 
end up being created and added to the tree, plus of course, once they're 
created and available in the main tree, various overlays can use them as 
well, for go-based packages that don't make it into the main tree.


OK, so following the debate has been interesting, in a generic way, but 
until now I hadn't the slightest hint of any go-based packages I might 
have the remotest practical interest in.


Now I read about this go-based news client, and suddenly, all that debate 
is at least somewhat relevant!  Not that I'm actually thinking of trying 
it; pan has been quite good to me over the years, but at least I have 
/some/ concept of an actual go-based package for something I actually do 
a bit of personally, even if I have a different app to handle things that 
I'm quite happy with.


Meanwhile, all this supports the point I was making earlier about side 
discussions suddenly proving relevant.  Reading that thread on the dev-
list, I had no clue I'd come across a go-based news client here, making 
that thread at least somewhat relevant.  And reading this thread here, I 
had absolutely no clue go was going to suddenly popup in the middle of 
it.  But the two entirely separate threads on two totally different 
lists, suddenly make each other relevant!

It's exactly that sort of totally unexpected connection that continues to 
keep newsgroups and mailing lists exciting for me, even after I'm 
familiar enough with the subject matter that to the degree one can 
predict things, anyway, it should long ago have bored me to death, or at 
least to the point I dropped my participation in that group/list.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman