headers
Carl Gay | 13 May 19:50
Favicon

Me and IRC

I don't have time to pay attention to #dylan anymore, so if you find a problem
with my commits please either reply to my commit mail or send me email
directly.

I'll take a look at this:

<turbo24prg!n=turbo24p <at> 80.244.253.241> make-regexp-positioner was renamed to ..-regex-... but
where did translate go?
@1206028618 <housel!n=nnhousel <at> 193.34.25.61> could it have gone away entirely?
@1206029688 <turbo24prg!n=turbo24p <at> 80.244.253.241> http://article.gmane.org/gmane.comp.lang.dylan.gwydion.cvs/7119/match=translate
@1206029696 <turbo24prg!n=turbo24p <at> 80.244.253.241> there it got removed

My recollection is that translate seemed to belong in string-extensions rather
than regular-expressions, so I thought I moved it there, but I guess not.  I'll
try compiling melange to see what the problem is and fix it.

-Carl

_______________________________________________
hackers mailing list
hackers <at> lists.opendylan.org
https://www.opendylan.org/mailman/listinfo/hackers
Permalink | Reply | 0 comments |
headers
Carl Gay | 1 May 18:55
Picon

logged-in?

Hi.  Does anyone know what replaced logged-in? in the web-framework
library?  It was removed in r11330 but I don't see what replaced it.

Thanks.
-Carl
_______________________________________________
hackers mailing list
hackers <at> lists.opendylan.org
https://www.opendylan.org/mailman/listinfo/hackers
Permalink | Reply | 1 comment |
headers
Hugh Greene | 29 Apr 00:34

Re: [hackers] Limited collections and type-for-copy

without-lurking

On Monday 28 Apr 2008 01:40, agentmail <at> gmail.com wrote:
> Looking over the unit tests for Gwydion Dylan, I see that none of map,
> etc, work with limited collections. This is probably because type-for-
> copy returns limited collection types and those functions don't know
> how to instantiate limited collection types properly.

I haven't looked at the code, so the following is guesswork and hand-waving 
(and maybe not useful -- it is kinda late here :-)

> limited() returns a <limited-collection>. A <limited-collection> isn't
> actually a collection -- none of its superclasses is <collection>.
> Instead, it is basically a limited collection specifier. make on
> <limited-collection> calls make-limited-collection to instantiate the
> actual collection.
>
> The actual collection (which inherits from <limited-collection-mixin>)
> has an additional init-keyword, collection-type:, beyond what the base
> collection class (<simple-vector> or whatever) has.
>
> type-for-copy doesn't treat <limited-collection-mixin> collections any
> differently from other collections, so calling type-for-copy returns
> the subclass of <limited-collection-mixin>. But when map tries to
> instantiate that type, it fails, because that type has the extra init-
> keyword parameter.

Well, going by the spec, map (and other methods which are defined to delegate 
to type-for-copy) should only be expected to work for those limited 
collection types which are instantiable (the concrete
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Swank | 24 Apr 04:40
Picon

[hackers] simple build question on linux x86_64

Trying to compile the towers of hanoi example I get:
    Internal error: : Link failed: don't know how to build <hanoi>hanoi.o

My build command is:

/usr/local/opendylan-1.0beta5/bin/opendylan -build hanoi.hdp

Where opendylan is a shell script similar to http://paste.lisp.org/display/44077

All the system dependencies seem to build ok.

Matt

_______________________________________________
hackers mailing list
hackers <at> lists.opendylan.org
https://www.opendylan.org/mailman/listinfo/hackers
Permalink | Reply | 0 comments |
headers
Carl Gay | 9 Apr 12:44
Favicon

wiki

Does anyone know what the status of the wiki sources is?
The code in libraries/network/wiki has been in a seriously
broken state for quite some time now due to changes made
in koala without updating all the callers.

-Carl
--

-- 
Gd-hackers mailing list
Gd-hackers <at> gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers
Permalink | Reply | 5 comments |
headers
Dustin Voss | 15 Feb 04:03
Picon

Gwydion Dylan macro parsing error

Gwydion Dylan seems to have a bug in its macro processing, which I've  
logged as #7369. The problem is that final semicolons can't be omitted  
from a defining macro call. The bug includes a brief sample to  
demonstrate the problem, and Open Dylan doesn't have a problem.

I think I've fixed it, but I wanted to run it past the group before  
checking it in. The code had special logic for semicolon-separated  
fragment matching vs. comma-separated fragment matching, and there may  
have been a reason for that which I'm unaware of.

Anyway, since the comma-separated fragment matching code works as I  
expect from reading the DRM (p. 151-152, http://www.opendylan.org/books/drm/Patterns) 
, my proposed fix simply applies the same logic to both the semicolon-  
and comma-separated cases.

Here is the diff:

Index: d2c/compiler/parser/support.dylan
===================================================================
--- d2c/compiler/parser/support.dylan	(revision 11673)
+++ d2c/compiler/parser/support.dylan	(working copy)
@@ -425,33 +425,15 @@
  define generic remove-optional-semi-and-end (pattern :: <pattern>)
      => (new-pattern :: <pattern>, found-end? :: <boolean>);

-define method remove-optional-semi-and-end (pattern :: <semicolon- 
pattern>)
+define method remove-optional-semi-and-end
+    (pattern :: type-union(<semicolon-pattern>, <comma-pattern>))
      => (new-pattern :: <pattern>, found-end? :: <boolean>);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Danny Milosavljevic | 9 Feb 20:41

compile error - GNU/Linux - "S_IFMT" undeclared

Hi,

I just tried to update Gwydion Dylan from SVN on my Gentoo Linux box and 
got this:

----------------------------------------------------
gcc -Wall -Wno-unused-variable -I.  -O2 -fno-strict-aliasing -
D_POSIX_C_SOURCE -I/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/
src/d2c/runtime -I/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/src 
-DGD_PLATFORM_LINUX -D_POSIX_C_SOURCE  -I/var/tmp/portage/dev-lang/
gwydion-dylan-2.4.99/work/src/common/io -c /var/tmp/portage/dev-lang/
gwydion-dylan-2.4.99/work/src/common/io/unix-portability.c -o unix-
portability.o
/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/src/common/io/unix-
portability.c: In function 'io_fd_info':
/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/src/common/io/unix-
portability.c:17: error: 'S_IFMT' undeclared (first use in this function)
/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/src/common/io/unix-
portability.c:17: error: (Each undeclared identifier is reported only once
/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/src/common/io/unix-
portability.c:17: error: for each function it appears in.)
/var/tmp/portage/dev-lang/gwydion-dylan-2.4.99/work/src/common/io/unix-
portability.c:17: error: 'S_IFREG' undeclared (first use in this function)
make: *** [unix-portability.o] Error 1
----------------------------------------------------

If I add 
  #define _XOPEN_SOURCE 500
to the beginning of "portability.c", it works.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kim Barrett | 9 Feb 17:00

new type hierarchy encoding

Just received my PoPL 2008 proceedings yesterday; this might be of 
interest to some of you.

"Extensible Encoding of Type Hierarchies", Alavi, Gilbert, & 
Guerraoui, PoPL 2008.

Abstract:
The subtyping test consists of checking whether a type t is a 
descendant of a type r (Agrawal et al. 1989). We study how to perform 
such a test efficiently, assuming a dynamic hierarchy when new types 
are inserted at run-time. The goal is to achieve time and space 
efficiency, even as new types are inserted. We propose an extensible 
scheme, named ESE, that ensures (1) efficient insertion of new types, 
(2) efficient subtyping tests, and (3) small space usage. On the one 
hand ESE provides comparable test times to the most efficient 
existing static schemes (e.g.,Zibin et al. (2001)). On the other 
hand, ESE has comparable insertion times to the most efficient 
existing dynamic scheme (Baehni et al. 2007), while ESE outperforms 
it by a factor of 2-3 times in terms of space usage.
--

-- 
Gd-hackers mailing list
Gd-hackers <at> gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers
Permalink | Reply | 0 comments |
headers
Peter Robisch | 4 Feb 10:04
Picon

Proposing several wiki instances for the community's webpresence

Good morning, Open Dylan Community,

   In my last email I stated that I currently use the current wiki 
instance to prepare the content a new Dylan book only. I presented 
in that email also a short content outline for such a book. 
   Several reader might have a belly or a head ache with this. So let me 
introduce you to the big picture I have in mind. 

  As the title of this email states I'm proposing here several wiki
instances for the community's webpresence. I especially see two additional
instances:

   *  dylan-annotated.opendylan.org
   *  dylan-reference-request.opendylan.org

IMHO:
    As soon as the wiki is based on the parser system Monday 
    it is time to start these instances.

==   dylan-annotated.opendylan.org ==

*  I first thought drm-annotated is the name for this instance, but 
   now I think it is better to use this more general name:
       dylan-annotated

*  The content of the dylan-annotated instance is outlined in a way 
   that it is mostly in parallel to the chapters of the DRM 
   (Dylan Reference Manual)

    **   There is already a collection of possible content
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Robisch | 3 Feb 22:11
Picon

Why and how I use both paste.lisp.org and the wiki

== Ways to promote Dylan ==

Here I describe my thoughts of promoting Dylan:
     "Publish a Dylan book directed to students of Computer Science" 
could be a way.

*  My contribution to the wiki are motivated by this goal. 
        -  I believe that the outline of the wiki can be a good base 
           for a new Dylan book
        -  I don't believe that the content of the wiki will 
           ever have a ready-to-print quality. 
        -  I have the hope that at one day the wiki contains
           enough content that it is easy for several Open Dylan 
           Community members to join to write the book
         -  Attached to the end of this mail you will a section 
           "Outlining a Dylan Book Project"
*  This also means
        -  I'm not interest to do earlier drafts inside the wiki. 
           Under an earlier drafting I understand to write down a 
           sudden inspiration.

Other ideas which to not relate to the book idea in mind, I paste to
the #dylan channel via paste.lisp.org. 
For example, I started the following pastes.

*   Paste number 54106: Recommend web site updates
    http://paste.lisp.org/display/54106 

    related to web presentation of the Open Dylan Community
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bastian MŸüller | 3 Feb 02:55
Picon

Koala update

Hej,

as already discussed in #dylan, i'd like to put some effort
into koala. The changes include:

(1) Replace the simple URI handling with a mostly RFC 3986
     compliant URI library soon to be put into /libraries/.
     Currently, koala percent-decodes the whole URL, ie.
     destroys it.

(2) Replace the date handling in the logging functions with
     format-date.

(4) Create some macros that keep the URL <=> responder mappings
     at a central place. hannes suggested something like
     (including my ideas):

   define responders
     "/foo/" (regex)      // with argument-regex (see below)
     begin
       method1;           // several methods
       method2;
       method3
     end,
    "/bar/" (regex)
       method4,
    "/baz/" ()            // without argument-regex
       method5,
    "/blub",              // normal page-responder
       method6,
(Continue reading)

Permalink | Reply | 7 comments |

Gmane