Custom Query (1630 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (43 - 45 of 1630)

Ticket Resolution Summary Owner Reporter
#427 fixed salmonella does not report errors in .meta files. Alan Post
Description

I had a bug in my kiksispehi egg, which I fixed in r21262. This bug was a syntax error in my .meta file.

Before this fix, salmonella did not report an error in this package, it treated the egg as if it did not exist. I'm not sure if this was because there were no other files in the egg directory, but this *was* the case for this error.

I believe a syntax error in an egg's .meta file should be flagged as an error, just as a missing .setup file is reported:

http://tests.call-cc.org/2010/11/03/salmonella-report/jbogenturfahi.html

#430 fixed commit cbb27fe380ff8e45cdf04d812e1ec649bf45ca47 not (always) compatible with DSSSL key arguments Alan Post
Description

I have started getting a compilation error in my egg, genturfahi. Here is the error:

Error: nunjavni.scm:131: procedure `javni-*' called with wrong number of arguments

This procedure usses DSSSL #!key arguments. It is being called with the correct number of arguments, as you can see by looking at the source code:

source:release/4/genturfahi/trunk/nunjavni.scm@21431#L113

This is the simplest test case that I've managed to create which causes this error:

(define (foo)
  (define (bar #!key a)
    (define (baz)
      (bar a: #t))
    baz)
  bar)

Compiling the above code with csc (csc -o key key.scm) produces the error:

Error: key.scm:4: procedure `bar' called with wrong number of arguments

But it very clearly does have the correct number of arguments. I would expect the above code to compile without this error message.

If I remove the #!key support, the code compiles fine.

More simplistic cases using #!key arguments don't seem to trigger this error. The above code snippet is the simplest test case I was able to create that demonstrates the problem.

When I revert cbb27fe380ff8e45cdf04d812e1ec649bf45ca47, the genturfahi egg compiles and passes all of its tests.

#433 invalid #!key args not assigned when |eval| called on compiler output Alan Post
Description

Set Up

This ticket is a follow-up to the e-mail thread I posted about this issue.

I'm running chicken from the experimental branch, version 04af68b541adab8dcaa24dd0915c7e68de6eb7ed. [fixed bug in ##sys#halt (thanks to Jeronimo Pellegrini)]

I'm running OpenBSD 4.8 on i386 in a VMWare virtual machine.

This bug refers to the genturfa'i egg.

For this bug, please check out r21579 from the egg repository and build the egg:

svn co -r21579 https://code.call-cc.org/svn/chicken-eggs/release/4/genturfahi/trunk
cd trunk
chicken-install -s -test

This revision of the egg should pass all of its tests.

Expected vs Actual Result

The problem that I'm having is that the routine test-samselpla-re does not get it's #!key argument (|gerna|) assigned in all cases in which it is called, even though the #!key name is passed as a parameter to the function each time.

This routine is called in three ways:

  1. By directly including the parser in the test.
  2. By parsing re.peg using the bootstrap compiler, writing the output of the compiler to a port, and reading the port back and calling eval on the result.
  3. By parsing re.peg using the bootstrap compiler, and calling eval directly on the results. Note that this is the same compiler (bootstrap.scm) compiling the same input file (tests/re.peg) as option #2.

option #1 and #2 work as expected. Option #3 does not assign #!key arguments, through the same argument list is passed to test-samselpla-re in each of the three cases.

option #3 is currently commented out, and will need to be uncommented to see this bug. Each option is grouped at the bottom of the tests/re.scm file.

I would expect option #3 to work like option #1 and option #2, passing the test suite for this PEG grammar.

Detailed Debugging Information

Because the volume of code for this bug is so large, I provide here pointers to the relevant sections.

The runtime system for the compiler is responsible for calling test-samselpla-re. That call is performed by the function generated by nunjavni-samselpla.

That routine generates the parse tree by calling the variable nunjavni, filtering out any result without an associated name (called cmene or cme), and creating the argument list by appending the key/value pairs, which are then applied to the supplied routine.

Looking at the inlined compiler output in option #1, you can see that nunjavni-samselpla is called with test-samselpla-re as one of it's arguments. This is done again in option #2 and option #3.

You can see the output produced by the parser by running the following command from the svn checkout:

genturfahi-peg tests/re.peg

It compiles tests/re.peg:

gerna <- #gerna: (digit / alpha)* FAhO {test-samselpla-re}
digit <- [:digit:]+
alpha <- [:alpha:]+
FAhO  <- !.

Into the following scheme code, which is the code being evaluated in option #2 and option #3:

(letrec ((gerna (nunjavni-morji
                  (nunjavni-samselpla
                    test-samselpla-re
                    (nunjavni-je
                      (nunjavni-*
                        (nunjavni-jonai
                          (nunjavni-cmene
                            (nunjavni-naselci digit)
                            cmene:
                            'digit:)
                          (nunjavni-cmene
                            (nunjavni-naselci alpha)
                            cmene:
                            'alpha:))
                        cmene:
                        'gerna:)
                      (nunjavni-cmene
                        (nunjavni-naselci FAhO)
                        cmene:
                        'FAhO:)))))
         (digit (nunjavni-morji (nunjavni-re "[[:digit:]]+")))
         (alpha (nunjavni-morji (nunjavni-re "[[:alpha:]]+")))
         (FAhO (nunjavni-morji (nunjavni-fanmo))))
  gerna)

The test-samselpla-re routine is attached to the grammar rule |gerna| in order to return only the grammar, but not the end of input token.

Conclusion

I'm sorry that I have not been able to make this test case simpler. I know that there is a lot of code involved in recreating this problem, and I'm not certain I'm even seeing a bug.

If I have forgotten a useful piece of information, please ask me for clarification, as I obviously understand this code better than anyone else and can likely save time in determining what is going on.

Note: See TracQuery for help on using queries.