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
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 |
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
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
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
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)
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
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
>>>>> 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)
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)
RSS Feed8 | |
|---|---|
3 | |
1 | |
7 | |
6 | |
11 | |
10 | |
8 | |
1 | |
11 | |
4 | |
2 | |
30 | |
9 | |
1 | |
9 | |
5 | |
16 | |
3 | |
4 | |
2 | |
12 | |
6 | |
1 | |
19 | |
3 | |
3 | |
3 | |
1 | |
6 | |
4 | |
4 | |
7 | |
28 | |
9 | |
10 | |
9 | |
25 | |
12 | |
9 | |
10 | |
4 | |
28 | |
3 | |
4 | |
7 | |
11 | |
19 | |
6 | |
21 | |
17 | |
12 | |
12 | |
38 | |
18 | |
40 | |
14 | |
10 | |
3 | |
1 | |
16 | |
12 | |
7 | |
12 | |
4 | |
10 | |
11 | |
11 | |
18 | |
6 | |
20 | |
23 | |
13 | |
29 | |
35 | |
34 | |
18 | |
7 | |
16 | |
23 | |
7 | |
7 | |
18 | |
29 | |
17 | |
8 | |
37 | |
35 | |
30 | |
29 | |
31 | |
11 | |
11 | |
23 | |
17 | |
12 | |
8 | |
19 | |
24 | |
4 | |
6 | |
2 | |
6 | |
9 | |
1 | |
1 | |
7 | |
2 | |
2 | |
2 | |
7 | |
1 | |
2 | |
4 | |
6 | |
3 | |
9 | |
3 | |
8 | |
3 | |
8 | |
7 | |
4 | |
3 | |
9 | |
18 | |
2 | |
2 | |
1 | |
1 | |
8 | |
1 | |
4 | |
4 | |
7 | |
6 | |
22 | |
5 | |
3 | |
1 | |
2 | |
2 | |
6 | |
14 | |
4 | |
2 | |
5 | |
7 | |
2 | |
3 | |
21 | |
6 | |
9 | |
6 | |
5 | |
5 | |
22 | |
13 | |
3 | |
5 | |
6 | |
1 | |
12 | |
9 | |
1 | |
1 | |
4 | |
5 | |
4 | |
9 | |
6 | |
25 | |
15 | |
18 | |
1 | |
1 | |
6 | |
2 | |
23 | |
3 | |
8 | |
2 | |
3 | |
8 | |
8 | |
5 | |
13 | |
26 | |
29 | |
26 | |
12 | |
21 | |
34 | |
48 | |
16 | |
21 | |
18 | |
27 | |
26 | |
6 | |
6 | |
3 | |
1 | |
2 | |
8 | |
3 | |
2 | |
6 | |
1 | |
4 |
