Re: [Chicken-users] srfi-128 - almost

[Jörg F . Wittenberger]

The release-info worried me too - TLD; super simple: if nothing else 
changes, it should work as before.


To add it to the C5 coop send a note to the list that 
https://raw.githubusercontent.com/ThatGeoGuy/srfi-128/master/srfi-128.release-info 
it ready to go there.


Best

/Jörg

On Aug 18 2018, Jeremy Steward wrote:


On 08/18/2018 06:12 AM, Jörg F. Wittenberger wrote:

On Aug 18 2018, Jeremy Steward wrote:


Hey Joerg,

I'm the maintainer for that egg.


I know; we talked about that before as I had packaged the same srfi under
the name of "comparators" before.



Ah, right. Now I remember :)


I'd be happy to review the pull request,
but just haven't had time. I can look it over tomorrow if necessary to
get things merged in properly.


I did not want to be pushy. It's just a nice example of a situation where
I'd like to consult alternative sources than those baked into
chicken-install.



No worries, I needed to get on this (and several other eggs). I've 
reviewed the PR, and tested with both CHICKEN 4.12.0 and 5.0.0rc1, and 
it all seems to be in working order. I've merged the PR and we should be 
good to go. Couple of questions in general though:


 * How does updating the .release-info file work now, if you want to 
support CHICKEN 4 and 5 at the same time?


 * What do I need to do to add SRFI 128 to the coop?

Regards,



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

Re: [Chicken-users] srfi-34 egg

[Mario Domenech Goulart]

Hi Jörg,

On Sun, 19 Aug 2018 09:21:42 +0200 Mario Domenech Goulart 
 wrote:

> On 17 Aug 2018 20:40:02 +0200 Jörg F. Wittenberger 
>  wrote:
>
>> there is an srfi-34 egg here
>>
>> https://raw.githubusercontent.com/0-8-15/srfi-34/master/srfi-34.release-info
>>
>> https://github.com/0-8-15/srfi-34
>>
>> which compiles for me with both chicken 4 and chicken 5.
>>
>> Could go to the coop if it is done well.
>
> Thanks Jörg.  Your egg has been added to the coop.

It looks like the tags and the references in the .release-info file are
inconsistent.  .release-info references a 0.6 tag, but the only tag in
the repository is 0.7.  Please, fix this.

All the best.
Mario
-- 
http://parenteses.org/mario

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

Re: [Chicken-users] srfi-128 - almost

[Jörg F . Wittenberger]

Thanks Mario,

at the end of the day your suggestion will solve the development time 
considerations I have. Except for the "check the download process" part.


Though actually rolling those out over a test network looks like a 
bookkeeping hell.


Brings me to a downside of C5 I'm seeing so far: I now need to tell it 
where it should maintain its cache. I wonder how I could maintain a 
consistent overwrite for setup.defaults for all the receipes in a yocto 
build. Plus where goes this new cache?


Best

/Jörg

On Aug 19 2018, Mario Domenech Goulart wrote:


On Sat, 18 Aug 2018 15:57:52 +0300 megane  wrote:


Hi Jörg,

Jörg F. Wittenberger  writes:

[...]
Brings back the question: how would I tell chicken to temporarily 
consult other locations for egg distributions? E.g. I'd like to use 
chicken-install in a fresh location outside the source directory of the 
egg to check that the whole download picks the correct files and all of 
them. Or maybe I just want to install an egg I deem not good enough to 
release.



Maybe you're looking for a custom entry in share/chicken/setup.defaults.
Maybe something like:

(server (location "/path/to/my/eggs") (transport local))


Actually just

 $ echo "(location $EGGS_DIR)" >> $PREFIX/share/chicken/setup.defaults

should be enough.

Where EGGS_DIR is the directory where directories containing egg source
code can be found and $PREFIX is the CHICKEN installation prefix (what
you provided as argument to PREFIX when compiling CHICKEN).

If the egg you try to install (or its dependencies) cannot be found in
$EGGS_DIR, chicken-install will fall back to the `server' configuration
in setup.defaults (which defaults to the primary egg server).

All the best.



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

Re: [Chicken-users] srfi-128 - almost

[Mario Domenech Goulart]

Hi Jörg,

On 20 Aug 2018 19:24:28 +0200 Jörg F. Wittenberger 
 wrote:

> The release-info worried me too - TLD; super simple: if nothing else
> changes, it should work as before.
>
> To add it to the C5 coop send a note to the list that
> https://raw.githubusercontent.com/ThatGeoGuy/srfi-128/master/srfi-128.release-info
> it ready to go there.

SRFI-128 has been added to the coop.  It's already be available to be
installed via chicken-install.

All the best.
Mario
-- 
http://parenteses.org/mario

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

[Chicken-users] C5 egg format and data files organized in multiple subdirectories

[Ivan Raikov]

Hi all,

One of my eggs includes a number of data files that are organized in
sub-folders, and I was wondering what would be the best way to
represent this file structure in the C5 egg file. I see from the
documentation that a `destination' property can be specified for data
components, but that appears to be an absolute path. Is there a way to
specify a relative path, or is there an alternative? Thanks and best
regards,

-Ivan

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

Re: [Chicken-users] New C5 eggs: llrb-syntax

[Jörg F . Wittenberger]

Done.

Reference removed.

On Aug 19 2018, Mario Domenech Goulart wrote:

On Sun, 19 Aug 2018 09:23:19 +0200 Mario Domenech Goulart 
 wrote:


On 18 Aug 2018 20:17:00 +0200 Jörg F. Wittenberger 
 wrote:



nothing changed, just ported

 
 
https://raw.githubusercontent.com/0-8-15/llrb-syntax/master/llrb-syntax.release-info


Thanks, Jörg.  Your egg has been added to the coop.


I just noticed the .release-info file for llrb-syntax references a tag
which is not in the repository (0.1).  Please, either push the tag or
remove the reference to it from the .release-info file.

All the best.
Mario



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

Re: [Chicken-users] http-client help needed with basic authorization

[Jörg F . Wittenberger]

On Aug 20 2018, Peter Bex wrote:


On Mon, Aug 20, 2018 at 02:47:25PM +0200, Jörg F. Wittenberger wrote:

I'm trying to use the http-client to talk to a Jira installation.

Without much success.

Jira is documented to support Basic authentication. However it defaults 
to and advertices OAuth. For the case at hand, a script reading some 
data, it OAuth looks like wasteful overhead.


The idea is to supply an "Authorization" header right with the request.


http-client comes with built-in basic auth support.  Just put a username
and password in the URL's authorization component.


That's what I tried first.  :-/


Any hints welcome.

So far I have this:

(define (insightc-query!2 uri . more)
 (define (basic-auth username pw)
   (string-append
"Basic "
(basic-auth-param-subunparser `((username . ,username) (password .
,pw
   #;`#(Basic ((username . ,username) (password . ,pw)))
   #;`#(Basic (,(basic-auth-param-subunparser `((username . ,username)
(password . ,pw)
  )
 (let* ((uri (update-uri uri host: "localhost" port: 7070 path: (append
(uri-path uri) more)))
(username "jwi")
(pw (call-with-input-file ".password" read))
(hdr (headers `((authorization ,(basic-auth username pw)
(req (make-request uri: uri headers: hdr)))
   (call-with-response req (lambda (x) #f) insightc-response-handler)))

Error: (unparse-headers) could not unparse "Authorization" header 
(#("Basic and... ...=" Error: (unparse-headers) could not unparse 
"Authorization" header (#("Basic and... ...="

Call history:

intarweb.scm:724: ##sys#print   


If you want to pass a raw string through the request unparser, convert it
to a blob.  Then it will be taken as-is, iirc.


Ah, great, that might do the trick.  Will try tomorrow.


Cheers,
Peter



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

Re: [Chicken-users] srfi-128 - almost

[Mario Domenech Goulart]

Hi Jörg,

On 20 Aug 2018 19:33:24 +0200 Jörg F. Wittenberger 
 wrote:

> Thanks Mario,
>
> at the end of the day your suggestion will solve the development time
> considerations I have. Except for the "check the download process"
> part.
>
> Though actually rolling those out over a test network looks like a
> bookkeeping hell.
>
> Brings me to a downside of C5 I'm seeing so far: I now need to tell it
> where it should maintain its cache. I wonder how I could maintain a
> consistent overwrite for setup.defaults for all the receipes in a
> yocto build. Plus where goes this new cache?

You can use the CHICKEN_EGG_CACHE environment variable [1] to configure
the location of the cache.

[1] http://wiki.call-cc.org/man/5/Extension%20tools#the-egg-cache

All the best.
Mario
-- 
http://parenteses.org/mario

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

Re: [Chicken-users] [ANN] CHICKEN 5.0.0 release candidate 1 available

[Kristian Lein-Mathisen]

Hi all,
and sorry about the late response on this one.

On my main Arch Linux, everything I tested has worked except building
statically against `check-errors` (ticket 1506
).

Operating system: Arch Linux
Hardware platform:  x86-64
C Compiler: GCC 8.2.0
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

I also tested this on a win10 with make PLATFORM=mingw-msys install check:

Operating system: Win10
Hardware platform:  x86-64
C Compiler: GCC 8.2.0 (rev1 msys2)
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Note that I had to install the "diff" tool to make the check succeed.
Here's a summary of the problems I encoutered with C5rc1 on Windows 10:

- when linking statically, csc is looking for ".o" files (Kooda is looking
into this I think) , improper patch here

- pathname wierdness, see this paste

- generated .install.bat file produces copy syntax error (see this
paste

)

Apart from these minor glitches, the CHICKEN 5 experience has been
wonderful.

I wanted to try static linking with CHICKEN 5 and this is the result, a
poor man's TeamViewer:
https://gist.github.com/kristianlm/16bbe626b54ad9b4e00fb8617d026bec
K.

On Sun, Aug 12, 2018 at 9:02 PM Peter Bex  wrote:

> Hi all,
>
> I also took some time to test on an old Hurd VM I had lying around.
>
> Operating system: Debian GNU/Hurd 0.9 (Mach 1.8+git20171101)
> Hardware platform: x86
> C Compiler: GCC 7.2.1
> Installation works?: yes
> Tests work?: yes
> Installation of eggs works?: yes
>
> Cheers,
> Peter
> ___
> 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

[Chicken-users] http-client help needed with basic authorization

[Jörg F . Wittenberger]

I'm trying to use the http-client to talk to a Jira installation.

Without much success.

Jira is documented to support Basic authentication. However it defaults to 
and advertices OAuth. For the case at hand, a script reading some data, it 
OAuth looks like wasteful overhead.


The idea is to supply an "Authorization" header right with the request.

Any hints welcome.

So far I have this:

(define (insightc-query!2 uri . more)
 (define (basic-auth username pw)
   (string-append
"Basic "
(basic-auth-param-subunparser `((username . ,username) (password . 
,pw

   #;`#(Basic ((username . ,username) (password . ,pw)))
   #;`#(Basic (,(basic-auth-param-subunparser `((username . ,username) 
(password . ,pw)

  )
 (let* ((uri (update-uri uri host: "localhost" port: 7070 path: (append 
(uri-path uri) more)))

(username "jwi")
(pw (call-with-input-file ".password" read))
(hdr (headers `((authorization ,(basic-auth username pw)
(req (make-request uri: uri headers: hdr)))
   (call-with-response req (lambda (x) #f) insightc-response-handler)))

Error: (unparse-headers) could not unparse "Authorization" header (#("Basic 
and... ...=" Error: (unparse-headers) could not unparse "Authorization" 
header (#("Basic and... ...="

Call history:

	intarweb.scm:724: ##sys#print	  



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

Re: [Chicken-users] http-client help needed with basic authorization

[Peter Bex]

On Mon, Aug 20, 2018 at 02:47:25PM +0200, Jörg F. Wittenberger wrote:
> I'm trying to use the http-client to talk to a Jira installation.
> 
> Without much success.
> 
> Jira is documented to support Basic authentication. However it defaults to
> and advertices OAuth. For the case at hand, a script reading some data, it
> OAuth looks like wasteful overhead.
> 
> The idea is to supply an "Authorization" header right with the request.

http-client comes with built-in basic auth support.  Just put a username
and password in the URL's authorization component.

> Any hints welcome.
> 
> So far I have this:
> 
> (define (insightc-query!2 uri . more)
>  (define (basic-auth username pw)
>(string-append
> "Basic "
> (basic-auth-param-subunparser `((username . ,username) (password .
> ,pw
>#;`#(Basic ((username . ,username) (password . ,pw)))
>#;`#(Basic (,(basic-auth-param-subunparser `((username . ,username)
> (password . ,pw)
>   )
>  (let* ((uri (update-uri uri host: "localhost" port: 7070 path: (append
> (uri-path uri) more)))
> (username "jwi")
> (pw (call-with-input-file ".password" read))
> (hdr (headers `((authorization ,(basic-auth username pw)
> (req (make-request uri: uri headers: hdr)))
>(call-with-response req (lambda (x) #f) insightc-response-handler)))
> 
> Error: (unparse-headers) could not unparse "Authorization" header (#("Basic
> and... ...=" Error: (unparse-headers) could not unparse "Authorization"
> header (#("Basic and... ...="
>   Call history:
> 
>   intarweb.scm:724: ##sys#print   

If you want to pass a raw string through the request unparser, convert it
to a blob.  Then it will be taken as-is, iirc.

Cheers,
Peter


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