Ezequiel Birman | 5 Jan 15:24 2008
Face
Picon

Re: Kali branch now up-to-date with latest devel changes

Thank you!

I had to manually install some files because some targets in the
Makefile would hang or give an error.

Is it possible to spawn two servers in the same scheme48 instance?

--

-- 
Ezequiel Birman

Michael Olson | 7 Jan 08:21 2008
Face
Picon
Picon

Re: Kali branch now up-to-date with latest devel changes

Ezequiel Birman <stormwatch <at> espiga4.com.ar> writes:

> Thank you!
>
> I had to manually install some files because some targets in the
> Makefile would hang or give an error.

I didn't test the install target in the Makefile, so it's quite possible
that there are bugs.

> Is it possible to spawn two servers in the same scheme48 instance?

It's easiest just to start two scheme48 instances, each with its own
server.  If you capture the *local-address-space* variable after
connecting each server, and let-bind it when passing requests, it might
be possible to run two servers on the same instance.

That said, it would be great if someone wanted to step up and maintain
this branch, because I won't be able to put any further effort into it.

--

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
          Programmer -- Hobbies: Lisp, HCoop          | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
Richard & Kristi Guay | 18 Jan 14:26 2008

close-socket

Hi,

I have been working on a multi-threaded server on a windows XP system 
with s48 as a side project and have run into a snag.  The close-socket 
always bombs!  So, if I unload a server, I have to totally stop the 
program and reload the program before reopening the same server socket.  
You have any ideas?

Also, do you have an example of extending s48?  I am not quite following 
the documentation for writing C++ extensions and I want to add SQLite 
and Sword for Windows access.

Thanks for your help.

Richard Guay

Michael Sperber | 19 Jan 15:17 2008
Picon

Re: close-socket


Richard & Kristi Guay <guay <at> tttmaxnet.com> writes:

> I have been working on a multi-threaded server on a windows XP system 
> with s48 as a side project and have run into a snag.  The close-socket 
> always bombs!  So, if I unload a server, I have to totally stop the 
> program and reload the program before reopening the same server socket.  
> You have any ideas?

Not immediately.  `close-socket' is tested as part of our test suite,
and doesn't have a known bug.  Could you post an example program that
demonstrates the problem?

> Also, do you have an example of extending s48?  I am not quite following 
> the documentation for writing C++ extensions and I want to add SQLite 
> and Sword for Windows access.

The next release of Scheme 48, due in a few days, will ship with two
substantial examples for external Scheme 48 code---the C support code
for SRFI 27 and the POSIX code.  (Well, the POSIX code is more
theoretical under Windows, of course.)  If you want a preview, you can
look at the s48-stable repo; see http://www.s48.org/development.html.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Ivan Shmakov | 27 Jan 08:57 2008
Picon

more-structures-interface: extra `srfi-35' and `srfi-36' members

	The `srfi-35' and `srfi-36' packages are mentioned in
	`more-structures-interface'.  Since there're no such packages
	defined in scheme/, I suggest them to be removed from the
	interface.

# HG changeset patch
# User "Ivan Shmakov <ivan <at> theory.asu.ru>"
# Date 1201420014 -21600
# Node ID 25901bf611a4c376189b47c3c323d724a27a0314
# Parent  d687c8fdbedf05e4344d8e193ecf5ee814ea0804
Removed mentions of absent `srfi-35' and `srfi-36'.
scheme/packages.scm
(more-structures-interface): Removed `srfi-35' and `srfi-36'.

diff -r d687c8fdbedf -r 25901bf611a4 scheme/packages.scm
--- a/scheme/packages.scm	Sat Jan 26 15:47:29 2008 +0100
+++ b/scheme/packages.scm	Sun Jan 27 13:46:54 2008 +0600
 <at>  <at>  -539,7 +539,7  <at>  <at> 
 	    srfi-1 srfi-2 srfi-4 srfi-5 srfi-6 srfi-7 srfi-8 srfi-9
 	    srfi-11 srfi-13 srfi-14 srfi-16 srfi-17 srfi-19
 	    srfi-23 srfi-25 srfi-26 srfi-27 srfi-28
-	    srfi-31 srfi-34 srfi-35 srfi-36 srfi-37
+	    srfi-31 srfi-34 srfi-37
 	    srfi-39 srfi-40 srfi-42 srfi-43 srfi-45
             srfi-60 srfi-61 srfi-62 srfi-63 srfi-66 srfi-67
 	    srfi-71 srfi-74 srfi-78

Ivan Shmakov | 27 Jan 09:56 2008
Picon

what about a `load-filename' structure?

	The following patch implements `load-filename' structure,
	providing two functions:

    (current-load-filename)

	-- return the filename of the file currently being `load'ed,
	   obtained from the internal fluid;

    (with-load-filename filename thunk)

	-- call `thunk' with the internal fluid being bound to
	   `filename' until `thunk' returns.

	This patch modifies `compile-and-run' in the `evaluation'
	structure so that the fluid will be rebound each time a file is
	being loaded, thus allowing SRFI 59 to be implemented in a
	straightforward manner.

# HG changeset patch
# User "Ivan Shmakov <ivan <at> theory.asu.ru>"
# Date 1201411462 -21600
# Node ID 6844d7b6ad3c0e1f46db2dabe6cfa2ad3316368b
# Parent  0c3fd5e363fbd28a67c5816e7c30aae1876d1bf7
New `load-filename' structure.
scheme/initial-packages.scm
(load-filename): New structure.
(evaluation): Open `load-filename'.
scheme/interfaces.scm (load-filename-interface): New interface.
scheme/rts/loadfn.scm: New file.
scheme/rts/eval.scm (compile-and-run): Wrapped the `invoke-closure'
(Continue reading)

Michael Sperber | 27 Jan 12:13 2008
Picon

Re: more-structures-interface: extra `srfi-35' and `srfi-36' members


Ivan Shmakov <ivan <at> theory.asu.ru> writes:

> 	The `srfi-35' and `srfi-36' packages are mentioned in
> 	`more-structures-interface'.  Since there're no such packages
> 	defined in scheme/, I suggest them to be removed from the
> 	interface.

Good point.  I've pushed the change.  Thanks!

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Michael Sperber | 27 Jan 12:14 2008
Picon

Re: what about a `load-filename' structure?


Ivan Shmakov <ivan <at> theory.asu.ru> writes:

> 	This patch modifies `compile-and-run' in the `evaluation'
> 	structure so that the fluid will be rebound each time a file is
> 	being loaded, thus allowing SRFI 59 to be implemented in a
> 	straightforward manner.

Looks interesting---do you have an implementation of SRFI 59 on top of
this?

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Ivan Shmakov | 27 Jan 12:48 2008
Picon

Re: what about a `load-filename' structure?

>>>>> Michael Sperber <sperber <at> deinprogramm.de> writes:

 >> This patch modifies `compile-and-run' in the `evaluation' structure
 >> so that the fluid will be rebound each time a file is being loaded,
 >> thus allowing SRFI 59 to be implemented in a straightforward manner.

 > Looks interesting---do you have an implementation of SRFI 59 on top
 > of this?

	Actually, yes.  I've somewhat extended it by turning the
	predefined vicinities into SRFI 39 parameters (so to allow these
	to be changed from within Scheme48), as well as simplified it
	since (IIUC) the directory separator in Scheme48 is always `/'
	(alas, this'll surely break would one try to use `in-vicinity's
	results in calls to, e. g., `system'.)

	Other issues with the implementation are:

	* `library-vicinity' is allowed to return `#f'; it isn't
	  explicitly allowed per SRFI 59, but what'd be its value when
	  there's no SLIB available on the system, or when Scheme48
	  doesn't know its location?

	* `home-vicinity' is allowed to return `#f' (e. g., if there's
	  no `HOME' in the environment); AIUI, it's allowed per SRFI 59;

	* `program-vicinity' may signal an error if called when no file
	  is being loaded, while its result is undefined per SRFI 59
	  (but note that the reference implementation signals an error
	  anyway); it may be better to return `#f' instead of signalling
(Continue reading)

Ivan Shmakov | 27 Jan 13:39 2008
Picon

allow the initial images to be built in parallel

	Currently, the initial images are first made as
	`SRCDIR/built/initial.image' and then are renamed to their
	designated names.  This patch makes them be built with their
	respective names in the first place, thus allowing them to be
	built in parallel (e. g., with -j 2.)

	(Not much an issue, but may be useful nevertheless.)

	The rest of the build system seems to already have support for
	parallel builds.

# HG changeset patch
# User "Ivan Shmakov <ivan <at> theory.asu.ru>"
# Date 1201437212 -21600
# Node ID 43f2807b79eb98d1ba007524ad96cc6325e4f647
# Parent  25901bf611a4c376189b47c3c323d724a27a0314
Allow the initial images to be built in parallel.
build/initial.scm (link-initial-system): Allow optional filename
argument, specifying the file to write the image to.
Makefile.in
($(INITIAL)-32): Prepare the image in the designated place at once
instead of using `mv'.
($(INITIAL)-64): Likewise.

diff -r 25901bf611a4 -r 43f2807b79eb Makefile.in
--- a/Makefile.in	Sun Jan 27 13:46:54 2008 +0600
+++ b/Makefile.in	Sun Jan 27 18:33:32 2008 +0600
 <at>  <at>  -673,6 +673,7  <at>  <at>  link/linker-in-lucid: build/lucid-script
 # no debugging environment to speak of.

(Continue reading)


Gmane