Re: Happy New Year

Happy new year etc. to those who deserve the greeting.

--

-- 
Tuomo

Re: Happy New Year

> Happy new year etc. to those who deserve the greeting.

:)

Tuomo has style, and I am serious.

Let me quote Adolf Loos, a g-e-n-i-a-l architect:

     On the subject of "home-furnishing" [Roy: it doesn't matter per se, it
     could have been on the subject of entomology, motocross or bread kneading
     too, though architects talk on these slightly less commonly] Loos liked
     to quote "that worthy housewife" (in other words, plain common sense)
     who, when asked what good style is, gave the following excellent reply:

     "When there's a lion's head on the bedside table, and this same lion's
     head is also on the couch, the cupboard, the beds, the armchairs, the
     washstand, in other words on everything on the room, THAT'S WHAT'S CALLED A
     ROOM WITH STYLE." [Emphasis added] ^1

QED

Which is of course a good omen for Ion. 

/Roy

     1. Adolf Loos, 1870-1933: Architect, Cultural Critic, Dandy; by August
Sarnitz, Taschen, 2003.

--

-- 
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS   bagai air di daun talas--as if water on a

Re: I'm very sad...

On Fri, Dec 21, 2007 at 04:45:36PM +0000, Tuomo Valkonen wrote:
> On 2007-12-21, Joerg van den Hoff <j.van_den_hoff@...> wrote:
> > -shared
> > -whole-archive
> > -export-dynamic
> 
> system.mk:
> 
> # Set PRELOAD_MODULES=1 if your system does not support dynamically loaded
> # modules through 'libdl' or has non-standard naming conventions.
> #PRELOAD_MODULES=1
> 
> That one option takes care of all that.
> 
> > and  librt:  is  that  supposedly  a  standard lib? it's not
> > there.
> 
> # clock_gettime for monotonic time
> EXTRA_LIBS += -lrt
> 
> (I suppose this could be better explained..)
> 
> Disable that, and if the MacOS X isn't totally brain-damaged,
> things should work (aside from setting the system clock confusing
> Ion's timers, if the POSIX monotonic clock isn't available through
> libc directly or so. But that's just an annoyance that was only
> recently fixed with support for the monotonic clock, where
> available).
> 
> ...

Re: I'm very sad...

On 2008-01-02 14:28 +0100, Joerg van den Hoff wrote:
> tuomo:   you  know  that  I  don't  like  this  scenario  of
> "everybody compiles from scratch on  his  own"   (it  simply
> burns  time  again  and again) and I know you probably won't
> alter your attitude. so, maybe you could  start  to  provide
> alternate  `system.mk' versions or at least the patch files?
> this one could be called, e.g.

I have suggested using the scripts repo for all the build files
needed on different platforms. Please submit those patches to
it (via darcs, if you can, or send on the ML and maybe someone
else will submit).

I have also added some documentation to system.mk, which should 
make it a bit easier to modify to your needs. (This also means
that your patch may no longer apply. The full old system.mk
should work, though.) It is attached. Comments?

--

-- 
Tuomo

##
## System settings
##

##
## Installation paths
##

Re: I'm very sad...

On Wed, Jan 02, 2008 at 05:01:38PM +0200, Tuomo Valkonen wrote:
> On 2008-01-02 14:28 +0100, Joerg van den Hoff wrote:
> > tuomo:   you  know  that  I  don't  like  this  scenario  of
> > "everybody compiles from scratch on  his  own"   (it  simply
> > burns  time  again  and again) and I know you probably won't
> > alter your attitude. so, maybe you could  start  to  provide
> > alternate  `system.mk' versions or at least the patch files?
> > this one could be called, e.g.
> 
> I have suggested using the scripts repo for all the build files
> needed on different platforms. Please submit those patches to
> it (via darcs, if you can, or send on the ML and maybe someone

darcs: I installed it once, but don't really know how to use
it. if I find time, I'll give it a try. otherwise I'd prefer
the ML. but such patches to system.mk rapidly go out of sync
with the actual state of  affairs,  i.e.  they  are  version
dependent, obviously. so, if they really make sense (to you,
that is), why not inlcude them  (even  "post-release"  time)
with  sensible  names  in the tarball together with a README
addendum? actually, this is of  course  what  the  different
distros do, when they include a package. one will not get it
100% watertight but sure it will help to reduce the  pain  a
bit.

> else will submit).
> 
> I have also added some documentation to system.mk, which should 
> make it a bit easier to modify to your needs. (This also means
> that your patch may no longer apply. The full old system.mk

Re: I'm very sad...

On 2008-01-02, Joerg van den Hoff <j.van_den_hoff@...> wrote:
> but such patches to system.mk rapidly go out of sync
> with the actual state of  affairs,  i.e.  they  are  version
> dependent, obviously. so, if they really make sense (to you,
> that is), why not inlcude them  (even  "post-release"  time)
> with  sensible  names  in the tarball together with a README
> addendum? 

You stated the reason yourself. I will not include things in
Ion that I can not or am not willing to maintain. The scripts
repository as a "poor man's wiki" is a much better place.

> what is DIST:? 

That's just stuff in the source repository. The release scripts
replace the following line with the DIST-line for release.

> --add two lines:
> #under Mac OS X (using macports) you'll need
> LDFLAGS=-L/opt/local/lib $(LIBS) $(EXTRA_LIBS)

As started earlier in the file, changing LDFLAGS etc. should not
be needed with GCC. -L option should go in the _LIBS option for
the library that needs it.

--

-- 
Tuomo

ion-3rc-20080103

This release features a few minor fixes to behavioural regressions
in the previous release, as well as some build configuration file
self-documentation improvements.

I am hoping for this to be the last RC...

--

-- 
Tuomo

Re: Nagware version

On 2007-12-29, Tuomo Valkonen <tuomov@...> wrote:
> I've been considering releasing (as a patch) a separate nagware version
> of Ion, which would have a license without the 28-day clause. 

I take it there's no interest for such a "free" nagware version?

--

-- 
Tuomo

bryan.richter@...: Fwd: Compile error under cygwin]

-- 
Tuomo

From: Bryan Richter <bryan.richter@...>
Subject: Fwd: Compile error under cygwin
Date: 2008-01-03 19:27:14 GMT

Tuomo, I keep getting bounced by berlios when I send mail through
Gmail's web interface. I will look and see if there is some Gmail
setting I can tweak. In the meanwhile, would you mind sending this to
the list?

Thanks,

-Bryan
aka chreekat

---------- Forwarded message ----------
From: Bryan Richter <bryan.richter@...>
Date: Jan 3, 2008 11:16 AM
Subject: Re: Compile error under cygwin
To: ion-general-request@...

bryan.richter-Re5JQEeQqe8AvxtiuMwx3w@...: Fwd: Compile error under cygwin]

(Bah, berlios or something is taking forever to send the mail back
to me, although gmane already has it. But the nntp interface/slrn
don't handle attachments well, so I'll just copy-paste quote.)

> The two problems with compiling Ion are
> (1) Windows does not have getloadavg, and with the way
> libextl_mkexports works, the only quick way to avoid this problem is
> to obliterate all references to getloadavg. This means deleting (not
> commenting out!) a couple functions and the whole file
> utils/ion-statusd/statusd_load.lua.

There's no real need to alter statusd_load, but cfg_statusbar should
perhaps be altered to not include the load meter. It gets a bit too
complicated to to properly. The altogether too hacky loadavg export
(some more general Lua lib should really provide all this!) can in
any case be easily #ifdef'd out. (DEFINES += -DCF_NO_GETLOADAVG)

> (2) Cygwin's gcc appends ".exe" to executables, which means Makefiles
> must be modified accordingly.

That's just utterly and totally brain-dead. If I say '-o ion3', 
then that's where the output should go, even if the rest of the
system can't handle the lack of a lame extension. I wonder if 
they have a modified variant of install-sh or so, that can 
handle the way they've fucked up gcc? The latest release actually
introduced the INSTALLBIN variable to take care of passing
the -s(trip) flag to install-sh nicely based on configuration.
Maybe gmake provides some macros that could be used to redefine
this to append the .exe idiocy to the source file.