gmane.comp.lang.dylan.gwydion.devel

Re: [chatter] r11972 - trunk/gwydion/common/io/streams

Peter S. Housel — 2008-11-15T20:58:36

That was an oversight on my part. For pipes, stream-size returns #f. In this case the method of pre-allocating the space needed for the remainder of the stream will not work, and so we have to fall back on reading one element at a time until end-of-file. I'll add a comment the next time I touch this file.

Re: [chatter] r11972 - trunk/gwydion/common/io/streams

Carl Gay — 2008-11-15T20:33:20

Why does this need to call stream.stream-size again? Why not use the-size instead? The reason for calling next-method here escapes me. Is it worth a comment, or should it be pretty obvious to anyone who knows anything about streams (unlike me)? -Carl _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

International Lisp Conference

Carl Gay — 2008-11-03T20:36:38

-------- Original Message -------- Subject: International Lisp Conference Date: Sun, 02 Nov 2008 06:19:38 -0500 From: Dan Weinreb itasoftware.com> CALL FOR SUBMISSIONS INTERNATIONAL LISP CONFERENCE 2009 Lisp: The Next 50 Years http://www.international-lisp-conference.org Massachusetts Institute of Technology Cambridge, Massachusetts, USA March 22-25, 2009 Sponsored by the Association of Lisp Users General Information: The Association of Lisp Users is pleased to announce the 2009 International Lisp Conference will be held in Cambridge, Massachusetts, at the Massachusetts Institute of Technology, Sunday through Wednesday, March 22-25, 2009. The emphasis will be on present and future applications of technologies that have been or might soon be associated with the Lisp programming language and/or related languages and software. We encourage submissions in diverse areas, including but not limited to: language design and implementation, memory management, software engineering, mathematical and scientific computing, artificial intelligence, database processing and data mining, business intelligence, performance analysis, parallel processing, quantum computing, bioinformatics, telecommunications and networking, the semantic web, music, domain-specific languages, and entertainment technologies. ILC09 is not limited to topics discussed in previous symposia. Authors concerned about the appropriateness of a topic may communicate by electronic mail with the program chair prior to submission. Explaining a known idea in a new way may make as strong a contribution as inventing a new one. We encourage the submission of "pearls": elegant essays that illustrate an idea, for example by developing a short program. (A pearl should be concise, instructive, self-contained, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing.) There is no formal separation of categories and no need to explicitly label pearls as such: all papers, whether pearl or otherwise, will be judged on a combination of correctness, significance, novelty, clarity, and elegance. Each paper should explain its contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Authors should strive to make their papers understandable to a broad audience. Alongside our usual four-day program of tutorials, prominent invited speakers, and excellent technical sessions, this year we will also consider demonstration sessions. The official language of the conference is English. Further details are available at the conference web site: http://www.international-lisp-conference.org Technical Program: Original submissions in all areas related to the conference themes are invited for the following categories. Papers: Technical papers of up to 15 pages that describe original results ("research papers") or explain known ideas in new ways ("pearls"). Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Panel discussions: Abstracts of up to 4 pages for discussions about current themes. Panel discussion proposals must mention panel members who are willing to partake in a discussion. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. Important Dates: Please send contributions before the submission deadline to the program committee (ilc09-program-committee at alu.org). Deadline for submissions: December 9, 2008 Notification of acceptance or rejection: January 9, 2009 Deadline for final paper submissions: February 9, 2009 Organizing Committee: Conference Chair: Daniel Weinreb (ITA Software) General correspondence: ilc09-organizing-committee at alu.org Program Chair: Guy L. Steele Jr. (Sun Microsystems Laboratories) Contact: ilc09-program-committee at alu.org Local chair: Howard Shrobe (MIT) Technical Program Committee: Guy Steele (chair), Sun Microsystems Laboratories Jerry Boetje, College of Charleston William Clinger, Northeastern University Pascal Costanza, Vrije Universiteit Brussel Jeff Dalton, University of Edinburgh Tim McNerney, ITA Software Henry Lieberman, MIT Julian Padget, University of Bath Christian Queinnec, Laboratoire d'Informatique de Paris Jon L White, The Ginger Ice Cream Factory / ALU David Wilkins, SRI Taiichi Yuasa, Kyoto University _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

Re: [chatter] r11967 - intrunk/libraries:registry/genericutilities/dynamic-bindingutilities/dynamic-binding/test

Peter Housel — 2008-11-03T18:33:35

BTW, though the threads library/module on GD mostly does nothing, dynamic-bind does work fine in GD. -Peter- _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

Re: [chatter] r11967 - in trunk/libraries: registry/generic utilities/dynamic-binding utilities/dynamic-binding/test

Dustin Voss — 2008-11-03T17:28:14

I have no idea what the trade-offs are, performance-wise. I assume that OD and GD keep their handlers in a thread-local stack, but I don't know. Functionally, this library is slightly better than global + dynamic- bind because it allows for varying types for the binding in each dynamic scope, slightly worse because of keeping track of dynamically bound names, and simply different in that you can ask for a dynamically scoped value and not have one available (in which case you can specify a default). But yeah, a major advantage is that it works for both GD and OD. On Nov 3, 2008, at 9:03 AM, Carl Gay wrote: _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

Re: [chatter] r11967 - in trunk/libraries: registry/genericutilities/dynamic-binding utilities/dynamic-binding/test

Carl Gay — 2008-11-03T17:03:24

This is pretty cool. I think it would be good, though, if you added something to this README explaining the trade-offs between this and Open Dylan's thread variables + dynamic-bind macro. I assume this is more expensive because it has to walk the stack to find matching condition handlers? Or maybe it's not, judging by a comment from Riastradh in #dylan on Oct 15 18:46:23 EDT. I assume the major benefit is that it works in both OD and GD? I guess I could write a benchmark. :-) -Carl _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

Buildbot, and a minor Gwydion change

Peter S. Housel — 2008-08-29T05:41:11

For those who hadn't noticed, we've now got a Buildbot running. Right now it does an automatic build whenever anything affecting Gwydion Dylan 2.5.x is committed; automatic builds for Open Dylan will come soon. You can monitor what the Buildbot is currently up to at http://www.opendylan.org/buildbot/ (trailing slash required). Right now we have builders and build hosts for - FreeBSD 8.0-CURRENT - Debian GNU/Linux 4.0 (Etch) - Mac OS X If you have a persistent network connection and another one of the platforms supported by Gwydion Dylan, and would like to volunteer a build host, let me know in e-mail or IRC. In order to improve the Buildbot "experience", I'd like to change the Gwydion build system slightly to split the running of the test suites out of the "make compile" target (the default target) and into a new "make check" target. This will make it easier to write some customization code for Buildbot to scan the test report and include it on the status page. Diff follows. Index: tools/shared-misc/gen-makefile.in =================================================================== --- tools/shared-misc/gen-makefile.in(revision 11926) +++ tools/shared-misc/gen-makefile.in(working copy) < at >< at > -139,7 +139,7 < at >< at > # where "makefileTarget" is the name of a Makefile target # # gen-makefile supports the following top-level makefile targets: -# compile (default), install, clean, and cc_files (compiles C code +# compile (default), check, install, clean, and cc_files (compiles C code # generated by d2c). $usage_message = "Usage: $0 [-pPlatforms.descr] [directory]\n"; < at >< at > -353,7 +353,7 < at >< at > print "BUILDDIR=$builddir\n"; print "DESTDIR=\n"; # GNU DESTDIR, not the $destdir variable. if ($host_platform{'make_supports_phony_targets?'}) { - print "\n.PHONY: default compile install uninstall clean\n\n"; + print "\n.PHONY: default compile check install uninstall clean\n\n"; } print "default: compile\n\n"; < at >< at > -374,6 +374,7 < at >< at > "$gen_makefile -p$platforms_dot_descr ."); &emit_rule('compile'); + &emit_rule('check'); $destdir && do emit_rule ('install'); $destdir && do emit_rule ('uninstall'); &emit_rule('clean'); < at >< at > -460,6 +461,9 < at >< at > push(< at >compile_commands, sprintf($host_platform{'recursive_make_command'}, $subdir, "")); + push(< at >check_commands, + sprintf($host_platform{'recursive_make_command'}, + $subdir, "check")); push(< at >install_commands, sprintf($host_platform{'recursive_make_command'}, $subdir, "install")); Index: qa/Makegen =================================================================== --- qa/Makegen(revision 11926) +++ qa/Makegen(working copy) < at >< at > -6,15 +6,17 < at >< at > "../common/io/tests", "../common/system/tests"); -foreach $testdir (< at >testdirs) { +foreach $testdir (< at >testdirs, "test-suites") { if ($features{'compiled_for_win32'}) { $testdir =~ s|/|\\|; } - push(< at >compile_commands, + push(< at >check_commands, sprintf($host_platform{'recursive_make_command'}, $testdir, "")); push(< at >clean_commands, sprintf($host_platform{'recursive_make_command'}, $testdir, "clean")); } -&compile_subdirs("test-suites", "test-apps"); - +push(< at >check_commands, + sprintf($host_platform{'recursive_make_command'}, "test-apps", "check")); +push(< at >clean_commands, + sprintf($host_platform{'recursive_make_command'}, "test-apps", "clean")); Index: qa/common-Makegen =================================================================== --- qa/common-Makegen(revision 11926) +++ qa/common-Makegen(working copy) < at >< at > -11,15 +11,11 < at >< at > sub emit_run_tests_rule { local (< at >tests) = < at >_; local ($test); - print "run_tests : "; - foreach $test (< at >tests) { -print "$test$dot_exe "; - } - print "\n"; foreach $test (< at >tests) { -local ($test) = &convert_path_separator("./$test"); -print "\t$test $testflags\n"; +push < at >check_dependencies, "$test$dot_exe"; + +local ($runtest) = &convert_path_separator("./$test"); +push < at >check_commands, "$runtest $testflags"; } - push(< at >compile_dependencies, "run_tests"); } Index: doc/Makefile.in =================================================================== --- doc/Makefile.in(revision 11926) +++ doc/Makefile.in(working copy) < at >< at > -6,11 +6,14 < at >< at > default: compile -.PHONY: default compile install clean +.PHONY: default compile check install clean compile: -echo 'Nothing to do.' +check: +-echo 'Nothing to do.' + install: compile ${INSTALL_DATA} dylan.7 ${DESTDIR}${MANDIR}/man7/dylan.7 ${INSTALL_DATA} gwydion.7 ${DESTDIR}${MANDIR}/man7/gwydion.7 _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

Re: Diff for Gwydion Dylan --dump-od switch

Dustin Voss — 2008-08-22T22:44:52

Um, it looks like the mailing list word-wrapped that message, making it useless for patching. Download "switch.diff" from http://public.me.com/d_j_v instead. On Aug 21, 2008, at 6:18 AM, Dustin Voss wrote: _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers

Re: Diff for Gwydion Dylan --dump-od switch

Dustin Voss — 2008-08-22T22:09:35

For those who missed the comment on IRC, this patch adds a --dump-du switch to GD. This switch creates a .lib.du.txt file in addition to the .lib.du file. The .txt file is a human-readable version of the .lib.du file. I had to add some features to the od-format library to get this to work, but these changes are all conditional and have no impact on pre- existing code. Specifically, I added an option to prevent loading objects from external data units, a class to handle references to said objects that is only used when that option is enabled, and support for additional informational parameters to object loader functions. The actual functionality of the --dump-du switch is in d2c/compiler/ main/text-du.dylan. This patch also includes an HTML file, d2c/compiler/base/od-format- description.html, that describes the format of various dumped objects. Without this, the .txt file is mostly useless. On Aug 21, 2008, at 6:18 AM, Dustin Voss wrote: _______________________________________________ hackers mailing list hackers< at >lists.opendylan.org https://www.opendylan.org/mailman/listinfo/hackers