[Chicken-users] Documentation for pthreads egg

[Joe Python]

Where can i get the html docs for the pthreads egg?
A link to it would be appreciated.
Thank you,
- Jo
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] A question regarding "hidden" eggs

[Kristian Lein-Mathisen]

Hi Jörg,

I think I may have bumped into similar needs now and again. I suppose one
way of solving this is to clone the henrietta-cache and run this on your
local server. However, I feel that's a little overkill if you just want a
work-in-progress egg to be available with any chicken-install.

I tried to set up my /usr/local/share/chicken/setup.defaults so that
chicken-install would first try my ~/prj/eggs/ folder, and then use the
server if that doesn't work. I never managed to set it up like that,
though, and I can't recall what went wrong. Would this approach solve your
problems though, Jörg?

K.

On Mon, Jan 18, 2016 at 2:22 PM, Jörg F. Wittenberger <
joerg.wittenber...@softeyes.net> wrote:

> Am 18.01.2016 um 14:13 schrieb Christian Kellermann:
> > * Jörg F. Wittenberger  [160116 19:35]:
> >> Hi,
> >>
> >> I feel the need to have some space to stash away temporary glue code.
> >>
> >
> > Is this about code you want to be able to chicken-install but noone
> > else should see it?
>
> Precisely.
>
> >> Ideally the current version of it is always empty and not of interest to
> >> anyone.  As documentation always lags behind, it is empty with high
> >> probability.  However development is not ideal.
> >
> > I don't understand this.
>
> I have some code to be ripped out of context and made available as eggs.
>  This code is well tested and comes with dependencies to things I would
> ideally rather replace with code from other eggs.  For transition and
> backward compatibility, I want to import some things from the "hidden"
> code.
>
> So it's all deprecated code right from the beginning.
>
> >> Not listing as in being marked as "(hidden)" in the meta file is
> >> apparently what I want.
> >
> > That does not make sense to me, if people can install it but should
> > not use it, what is it good for?
>
> Sure use it.  But not only indirect.  It should be outright clear and
> obvious that nothing implemented there is supposed to stay and be
> supported in future versions.  Nothing will be documented for re-use.  I
> don't want anybody to build anything at it an then complain when I
> eventually got around to remove something.
>
> >
> > If it is some code that your published eggs rely on, it will be public
> > in a way. Listing it in an egg index or hide it then does not make a
> > lot of a difference to me.
> >
> > But maybe I misunderstand what you really want to get done.
> >
> > Cheers,
> >
> > Christian
> >
> >
> > --
> > May you be peaceful, may you live in safety, may you be free from
> > suffering, and may you live with ease.
> >
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] A question regarding "hidden" eggs

[Jörg F . Wittenberger]

Am 20.01.2016 um 10:38 schrieb Kristian Lein-Mathisen:
> Hi Jörg,
> 
> I think I may have bumped into similar needs now and again. I suppose one
> way of solving this is to clone the henrietta-cache and run this on your
> local server. However, I feel that's a little overkill if you just want a
> work-in-progress egg to be available with any chicken-install.
> 
> I tried to set up my /usr/local/share/chicken/setup.defaults so that
> chicken-install would first try my ~/prj/eggs/ folder, and then use the
> server if that doesn't work. I never managed to set it up like that,
> though, and I can't recall what went wrong. Would this approach solve your
> problems though, Jörg?

This addresses another need of mine, which I have not figured out how to
solve well.  Yes, I'd too like to know how I could configure a local
chicken install to ask some self-maintained repository before consulting
the official repo.  (Though this repo would have to be on the net
somewhere, not on the local file system.)

But this solves only half the issue.  That way I can share code via
chicken-install with others who configure their chicken to look for my
source.

The other one is that in those eggs included in the official coop, I
sometimes need temporary work around missing code sequences.  I could
always literally include them, but that makes a bad source code.  I'd
rather like to use a "glue-egg".

> 
> K.
> 
> On Mon, Jan 18, 2016 at 2:22 PM, Jörg F. Wittenberger <
> joerg.wittenber...@softeyes.net> wrote:
> 
>> Am 18.01.2016 um 14:13 schrieb Christian Kellermann:
>>> * Jörg F. Wittenberger  [160116 19:35]:
 Hi,

 I feel the need to have some space to stash away temporary glue code.

>>>
>>> Is this about code you want to be able to chicken-install but noone
>>> else should see it?
>>
>> Precisely.
>>
 Ideally the current version of it is always empty and not of interest to
 anyone.  As documentation always lags behind, it is empty with high
 probability.  However development is not ideal.
>>>
>>> I don't understand this.
>>
>> I have some code to be ripped out of context and made available as eggs.
>>  This code is well tested and comes with dependencies to things I would
>> ideally rather replace with code from other eggs.  For transition and
>> backward compatibility, I want to import some things from the "hidden"
>> code.
>>
>> So it's all deprecated code right from the beginning.
>>
 Not listing as in being marked as "(hidden)" in the meta file is
 apparently what I want.
>>>
>>> That does not make sense to me, if people can install it but should
>>> not use it, what is it good for?
>>
>> Sure use it.  But not only indirect.  It should be outright clear and
>> obvious that nothing implemented there is supposed to stay and be
>> supported in future versions.  Nothing will be documented for re-use.  I
>> don't want anybody to build anything at it an then complain when I
>> eventually got around to remove something.
>>
>>>
>>> If it is some code that your published eggs rely on, it will be public
>>> in a way. Listing it in an egg index or hide it then does not make a
>>> lot of a difference to me.
>>>
>>> But maybe I misunderstand what you really want to get done.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> --
>>> May you be peaceful, may you live in safety, may you be free from
>>> suffering, and may you live with ease.
>>>
>>
>>
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/chicken-users
>>
> 


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth

[Jörg F . Wittenberger]

Nah, I did not forget to add that file.  Those modifications killed the
-emit-type-file from compile.

Sure this was still on my machine...

Tagged version 0.2.3.  salmonella eat it after removing the file.

Am 20.01.2016 um 01:16 schrieb Mario Domenech Goulart:
> Hello Jörg,
> 
> On Mon, 18 Jan 2016 18:20:50 +0100 Jörg F. Wittenberger 
>  wrote:
> 
>> Done.
>>
>> sqlite3pth now includes a slightly old version of sqlite3 (3.9.2).
>> Should compile with chicken-install.  Bonus: basic tests added.
> 
> Nice.  Thanks for improving it.
> 
> Installation still fails, though:
> 
>cp: cannot stat 'sqlite3pth.types': No such file or directory
> 
> Maybe you forgot to add this file to the repo?
> 
> Best wishes.
> Mario
> 


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users