Jens Thiele | 14 Apr 12:28 2014
Picon

shouldn't reverse raise an error on wrong type?

shouldn't reverse throw an error on wrong type?

gosh> (gauche-version)
"0.9.4_pre3"
gosh> (reverse #(1 2 3))
()

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
Jens Thiele | 12 Mar 20:46 2014
Picon

out-of-tree build broken at the moment?

Gauche$ ./DIST gen
Gauche$ cd .. && mkdir build && cd build && ../Gauche/configure && make -j2
[...]
GAUCHE_LOAD_PATH="" GAUCHE_DYNLOAD_PATH="" gosh -l../../Gauche/src/preload -I../../Gauche/src
-I../../Gauche/lib ../../Gauche/src/precomp -D LIBGAUCHE_BODY ../../Gauche/src/compile.scm
Error in compiling (include "compile-0")
*** ERROR: Compile Error: include file is not readable: "compile-0"
"../../Gauche/src/compile.scm":109:(include "compile-0")

Stack Trace:
_______________________________________
  0  (compile-in-current-tmodule form)
        At line 519 of "../../Gauche/lib/gauche/cgen/precomp.scm"
  1  fn

  2  (port-fold compile-toplevel-form '() read)
        At line 167 of "../../Gauche/lib/gauche/cgen/precomp.scm"
  3  (with-input-from-file src (cut emit-toplevel-executor (reverse (po ...
        At line 165 of "../../Gauche/lib/gauche/cgen/precomp.scm"
  4  (do-it src ext-initializer sub-initializers)
        At line 241 of "../../Gauche/lib/gauche/cgen/precomp.scm"
  5  keys

  6  (cgen-precompile src :out.c out.c :out.sci (or out.sci ext-module) ...
        At line 69 of "./../../Gauche/src/precomp"

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
(Continue reading)

Rui Ueyama | 24 Jul 03:03 2013
Picon

Making unit tests run fast

The slowest test in the Gauche unit test suite is system.scm which takes about 9 seconds to finish. In that file, the tests for sys-alarm is a dominant factor taking 7 seconds. These tests are slow because we have to wait one second for SIGALRM delivery after calling sys-alarm.

We cannot make these tests any faster because of the limitation of the system call, as long as we use alarm(). Is there anything we can do?

One idea would be to use setitimer() instead of alarm() to implement sys-alarm, and wait a shorter period of time in the tests.

Thoughts?
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Gauche-devel mailing list
Gauche-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gauche-devel
JP T | 23 Jul 18:15 2013
Picon

Gauche-user list?

Hi,

I was looking for some "gauche-user" mailing list or forum so I can
ask questions about using gauche (and not "developing it") to no
avail.

I think it would be great as generic scheme forums and lists are not
always a great source of help for gauche specific questions. (and I
may not want to disturb the developpers with simple usage questions).

But since I am here, my goal was to ask precision about this
particular error message that puzzle me...

"vm.c", line 1399 (user_eval_inner): Assertion failed:
SCM_COMPILED_CODE_P(program)

--
JP

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
Rui Ueyama | 22 Jul 19:51 2013
Picon

Managing Changelog

Most patches recently merged on GitHub, including mine, did not update Changelog file. Shiro-san seems to continue updating the file and check in changes with brief git commit messages different from Changelog messages. As a result we now have two commit logs both are incomplete.

Do we still want to keep Changelog file? Many projects migrated to Git removed that file and simply relies on Git logs. We could auto-generate Changelog from commit messages if we want.

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Gauche-devel mailing list
Gauche-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gauche-devel
Duy Nguyen | 2 Jul 04:29 2013
Picon

0.9.3.3 build error on SUSE Linux Enterprise Desktop 11.1 (x86_64)

Hi,

I got this error while building:

make[1]: Entering directory `/home/pclouds/t/Gauche-0.9.3.3/gc'
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
-I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src
-fexceptions -g -O2 -fno-strict-aliasing -DDONT_ADD_BYTE_AT_END -MT
allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo
allchblk.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2
-fno-strict-aliasing -DDONT_ADD_BYTE_AT_END -MT allchblk.lo -MD -MP
-MF .deps/allchblk.Tpo -c allchblk.c  -fPIC -DPIC -o .libs/allchblk.o
In file included from /usr/include/pthread.h:26,
                 from ./include/private/../gc_pthread_redirects.h:33,
                 from ./include/private/../gc.h:1249,
                 from ./include/private/gc_priv.h:46,
                 from allchblk.c:17:
/usr/include/time.h:226: error: expected declaration specifiers or
'...' before '__locale_t'
make[1]: *** [allchblk.lo] Error 1

I think it's because xlocale.h is somehow not included. Including
xlocale.h manually makes it work. This is glibc-2.11.1-0.32.1
--
Duy

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
Nguyễn Thái Ngọc Duy | 1 Jul 18:34 2013
Picon

[PATCH] Typo fix

---
 Quite new to Scheme and totally new to Gauche. Hopefully this is the
 right way of contributing..

 doc/modgauche.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/modgauche.texi b/doc/modgauche.texi
index b11d73a..75769bf 100644
--- a/doc/modgauche.texi
+++ b/doc/modgauche.texi
 <at>  <at>  -10350,7 +10350,7  <at>  <at>  The full syntax of  <at> var{hostspec} is  <at> code{protocol:user <at>  <at> hostname:port},
 where  <at> var{protocol:},  <at> var{user <at>  <at> }, or  <at> var{:port} part can be
 omitted.

-The  <at> var{protocol} part specifies the protocol to commnucate
+The  <at> var{protocol} part specifies the protocol to communicate
 with the remote host; currently only  <at> code{ssh} is supported, and
 it is also the default when  <at> var{protocol} is omitted.
 The  <at> var{user} part specifies the login name of the remote host.
--

-- 
1.8.2.83.gc99314b

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
Jens Thiele | 29 May 07:50 2013
Picon

selectively disable lambda lifting?

is there a way to selectively disable lambda lifting?
only found -fno-lambda-lifting-pass to disable it globally

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
Jens Thiele | 25 May 16:51 2013
Picon

gauche-gl simple viewer single threaded exit

i am not sure about this one / did only have a quick look

the quit-loop using (thread-terminate! (current-thread)) is not
good (at least in the single threaded case on debian/wheezy on X, the
window stays open and must be xkilled)
maybe something like below would help?
greetings
jens

diff --git a/lib/gl/simple/viewer.scm b/lib/gl/simple/viewer.scm
index fee729c..0afd80e 100644
--- a/lib/gl/simple/viewer.scm
+++ b/lib/gl/simple/viewer.scm
 <at>  <at>  -298,7 +298,9  <at>  <at> 

 (define (quit-loop)
   (cond-expand
-   [gauche.sys.pthreads (thread-terminate! (current-thread))]
+   [gauche.sys.pthreads (if (string=? (ref (current-thread) 'name) "root")
+                          (exit)
+                          (thread-terminate! (current-thread)))]
    [else (exit)]))

 ;; common key handler

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Jens Thiele | 1 May 15:10 2013
Picon

[Planet Debian] David Bremner: Exporting Debian packaging patches from git, (redux)*

hmm
there really isn't a nice and simple packaging workflow using git?

From: hmm there really isn't a nice and simple packaging workflow using git? <David>
Subject: David Bremner: Exporting Debian packaging patches from git, (redux)*
Newsgroups: Planet, Debian
Date: 2013-04-25 16:58:00 GMT

(Debian) packaging and Git.

The big picture is as follows. In my view, the most natural way to work on a packaging project in version control [1] is to have an upstream branch which either tracks upstream Git/Hg/Svn, or imports of tarballs (or some combination thereof, and a Debian branch where both modifications to upstream source and commits to stuff in ./debian are added [2]. Deviations from this are mainly motivated by a desire to export source packages, a version control neutral interchange format that still preserves the distinction between upstream source and distro modifications. Of course, if you're happy with the distro modifications as one big diff, then you can stop reading now gitpkg $debian_branch $upstream_branch and you're done. The other easy case is if your changes don't touch upstream; then 3.0 (quilt) packages work nicely with ./debian in a separate tarball.

So the tension is between my preferred integration style, and making source packages with changes to upstream source organized in some nice way, preferably in logical patches like, uh, commits in a version control system. At some point we may be able use some form of version control repo as a source package, but the issues with that are for another blog post. At the moment then we are stuck with trying bridge the gap between a git repository and a 3.0 (quilt) source package. If you don't know the details of Debian packaging, just imagine a patch series like you would generate with git format-patch or apply with (surprise) quilt.

From Git to Quilt.

The most obvious (and the most common) way to bridge the gap between git and quilt is to export patches manually (or using a helper like gbp-pq) and commit them to the packaging repository. This has the advantage of not forcing anyone to use git or specialized helpers to collaborate on the package. On the other hand it's quite far from the vision of using git (or your favourite VCS) to do the integration that I started with.

The next level of sophistication is to maintain a branch of upstream-modifying commits. Roughly speaking, this is the approach taken by git-dpm, by gitpkg, and with some additional friction from manually importing and exporting the patches, by gbp-pq. There are some issues with rebasing a branch of patches, mainly it seems to rely on one person at a time working on the patch branch, and it forces the use of specialized tools or workflows. Nonetheless, both git-dpm and gitpkg support this mode of working reasonably well [3].

Lately I've been working on exporting patches from (an immutable) git history. My initial experiments with marking commits with git notes more or less worked [4]. I put this on the back-burner for two reasons, first sharing git notes is still not very well supported by git itself [5], and second Gitpkg maintainer Ron Lee convinced me to automagically pick out what patches to export. Ron's motivation (as I understand it) is to have tools which work on any git repository without extra metadata in the form of notes.

Linearizing History on the fly.

After a few iterations, I arrived at the following specification.

  • The user supplies two refs upstream and head. upstream should be suitable for export as a .orig.tar.gz file [6], and it should be an ancestor of head.

  • At source package build time, we want to construct a series of patches that

    1. Is guaranteed to apply to upstream
    2. Produces the same work tree as head, outside ./debian
    3. Does not touch ./debian
    4. As much as possible, matches the git history from upstream to head.

Condition (4) suggests we want something roughly like git format-patch upstream..head, removing those patches which are only about Debian packaging. Because of (3), we have to be a bit careful about commits that touch upstream and ./debian. We also want to avoid outputting patches that have been applied (or worse partially applied) upstream. git patch-id can help identify cherry-picked patches, but not partial application.

Eventually I arrived at the following strategy.

  1. Use git-filter-branch to construct a copy of the history upstream..head with ./debian (and for technical reasons .pc) excised.

  2. Filter these commits to remove e.g. those that are present exactly upstream, or those that introduces no changes, or changes unrepresentable in a patch.

  3. Try to revert the remaining commits, in reverse order. The idea here is twofold. First, a patch that occurs twice in history because of merging will only revert the most recent one, allowing earlier copies to be skipped. Second, the state of the temporary branch after all successful reverts represents the difference from upstream not accounted for by any patch.

  4. Generate a "fixup patch" accounting for any remaining differences, to be applied before any if the "nice" patches.

  5. Cherry-pick each "nice" patch on top of the fixup patch, to ensure we have a linear history that can be exported to quilt. If any of these cherry-picks fail, abort the export.

Yep, it seems over-complicated to me too.

TL;DR: Show me the code.

You can clone my current version from

git://pivot.cs.unb.ca/gitpkg.git

This provides a script "git-debcherry" which does the history linearization discussed above. In order to test out how/if this works in your repository, you could run

git-debcherry --stat $UPSTREAM

For actual use, you probably want to use something like

git-debcherry -o debian/patches

There is a hook in hooks/debcherry-deb-export-hook that does this at source package export time.

I'm aware this is not that fast; it does several expensive operations. On the other hand, you know what Don Knuth says about premature optimization, so I'm more interested in reports of when it does and doesn't work. In addition to crashing, generating multi-megabyte "fixup patch" probably counts as failure.

Notes

  1. This first part doesn't seem too Debian or git specific to me, but I don't know much concrete about other packaging workflows or other version control systems.

  2. Another variation is to have a patched upstream branch and merge that into the Debian packaging branch. The trade-off here that you can simplify the patch export process a bit, but the repo needs to have taken this disciplined approach from the beginning.

  3. git-dpm merges the patched upstream into the Debian branch. This makes the history a bit messier, but seems to be more robust. I've been thinking about trying this out (semi-manually) for gitpkg.

  4. See e.g. exporting. Although I did not then know the many surprising and horrible things people do in packaging histories, so it probably didn't work as well as I thought it did.

  5. It's doable, but one ends up spending about a bunch lines of code on duplicating basic git functionality; e.g. there is no real support for tags of notes.

  6. Since as far as I know quilt has no way of deleting files except to list the content, this means in particular exporting upstream should yield a DFSG Free source tree.

link

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gauche-devel mailing list
Gauche-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gauche-devel
shuji yamamoto | 30 Apr 09:12 2013
Picon

generize -> , ->>

Hi all.
I wrote macro generized ->,->> of clojure.

(define-macro (-*> x form . more)
(if (pair? more)
`(-*> (-*> ,x ,form) , <at> more)
(if (pair? form)
(receive (head tail) (break (cut eq? '<*> <>) form)
(if (null? tail)
`(, <at> head ,x)
`(, <at> head ,x , <at> (cdr tail) ) ) )
`(,form ,x) ) ) )

#|
gosh> (-*> 1 (+ 12 <*>))
13
gosh> (-*> 1 (cut + 12 <*>))
#<closure #f>
gosh> (-*> 1 (cut + 12 <*>) (<*>) )
13
gosh> (-*> 1 (cut list 12 <*>) (<*>) )
(12 1)
gosh> (-*> 1 (cut list 12 <*> 67 ) (<*>) )
(12 1 67)
gosh> (-*> (quotient&remainder 13 5) (receive (x y) <*> (print x y)))
23
#<undef>
gosh> (-*> (quotient&remainder 13 5) (receive (x y) <*> (list x y)))
(2 3)

gosh> (-*> 'gauche (find-module <*>))
#<module gauche>
gosh> (-*> 'gauche (find-module <*>) (~ <*> 'table ) )
#<hash-table eq? 0x96f4ed8>
gosh> (-*> 'gauche (find-module <*>) (~ <*> 'table ) (~ <*> 'cond-list))
#<gloc gauche#cond-list>
gosh> (-*> 'gauche (find-module <*>) (global-variable-ref <*> 'cond-list))
#<macro cond-list>

gosh> (-*> 'gauche find-module )
#<module gauche>
gosh> (-*> 'gauche find-module module-exports)
()
gosh> (-*> 'gauche find-module d)
#<module gauche> is an instance of class <module>
slots:
name : gauche
mpl : (#<module gauche> #<module scheme> #<module null>)
parents : (#<module scheme>)
imports : (#<module srfi-1>)
exports : ()
export-all: #f
table : #<hash-table eq? 0x96f4ed8>
depends : ()
origin : #f
prefix : #f
gosh> (-*> 'gauche find-module (global-variable-ref <*> 'cond-list))
#<macro cond-list>

|#

And I make wiliki node for this
Gauche:Clojure:->,->>
http://practical-scheme.net/wiliki/wiliki.cgi?Gauche%3aClojure%3a-%3e%2c-%3e%3e

Shuji Yamamoto.
("yamasushi")

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

Gmane