Re: cvs commit: parrot/imcc imcc.l
Melvin Smith wrote: At 08:44 PM 1/9/2004 +, Harry Jackson wrote: So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. I think we are going to have an alternative to C.constant builtin to IMCC, the best suggestion seems to be C.define As far as macros, I guess we will keep them for the near future. I think its time to create a new branch for imcc development, so lets see how things work out. It may be that we can keep them in some form. One thing to consider: when we put an API on top of IMCC, macros won't translate; they are only for the text version. Thankfully this will not affect me. I am unable to find the email now but I remember someone mentioning breaking the pre-processor out of IMCC and into its own program, it was probably yourself. I have a few questions about this. What are the requirements on the pre-processor. I am pretty rusty with C and decided that I would oil my joints a little so I have been playing with a toy pre-processor (Thank god for KR). I know I should probably work with the one already there and not re-invent the wheel, I am also sure there are better ways to do it than the way I am doing it but.. ;-) This is as far as I have got and roughly how things are processed. $ preprocess filename.imc 1. Ignore comments where the *#* comes before text. If there is any text before the # I process the line as a normal statement # This line will not be processed .pcc_call blah # This line will be processed 2. Recursively process .include files ie .include /file/blah/blah goto step 1. 3. Store macro declarations in a hash table ie 146 .macro PQgetvalue(RES, tuple_num, count, data) 147 P0 = global PostgreSQL::PQgetvalue 148 I5 = .tuple_num 149 I6 = .count 150 P5 = .RES 151 invoke 152 .data = S5 153 .endm gets stored as PQgetvalue and a linked list holds each line up to the .endm. This is the area I need some clarification on. How is the current pre-processor handling arguments to the macros. Do they need to be pre-processed and if so in what ways. 4. Find macro calls by name assuming they have been found in Step 3 ie .PRINT(RES) and replace with the macro text. Using the name PRINT I access the hashtable traverse the linked list of lines printing them out as I go along. There are a few minor bugs in it which I am working on. I was just wondering what other types of things would the pre-processor need to handle. If you managed to get this far and are still interested. I have used a seriously hacked version of the dbj2 hash to store the macros. I had a look at the one in KR and thought I would have a look for a few others and this was the first one I found on google. http://www.cs.yorku.ca/~oz/hash.html Harry
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith [EMAIL PROTECTED] wrote: IMCC macros are gone. Volunteers feel free to reimplement a pre-processor (outside of IMCC) using the macro expansion code that was removed from IMCC. Melvin, that's not the way to go. We can remove them from the lexer, when we have an external substitute. Just removing it breaks a lot of existing code. Failing tests may hide other problems and so on. leo
Re: cvs commit: parrot/imcc imcc.l
At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: IMCC macros are gone. Volunteers feel free to reimplement a pre-processor (outside of IMCC) using the macro expansion code that was removed from IMCC. Melvin, that's not the way to go. We can remove them from the lexer, when we have an external substitute. Just removing it breaks a lot of existing code. Failing tests may hide other problems and so on. Which is why I hoped people would pitch in and help fix the tests. This is alpha code, and my approach is to do what needs to be done and force us to deal with it sooner than later. But, if you want macros to stay, let them stay. -Melvin
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith wrote: But, if you want macros to stay, let them stay. So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. H
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith [EMAIL PROTECTED] wrote: At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote: Melvin, that's not the way to go. We can remove them from the lexer, when we have an external substitute. Just removing it breaks a lot of existing code. Failing tests may hide other problems and so on. Which is why I hoped people would pitch in and help fix the tests. Its not tests only. There's already production code out there using parrot - ask Dan or read his blog. And of course macros are used not only in tests, they are in library code and so on. This is alpha code, and my approach is to do what needs to be done and force us to deal with it sooner than later. That's ok. But we also had some priorities nailed down. First is to fix current bugs and to finally implement the pdd03 changes. I know, that one bug is related to macros, but changing the generated labels from line-numbers to an incremented counter wil very likely fix that too. But, if you want macros to stay, let them stay. Currently yes, until there is an external macro processor. -Melvin leo
Re: cvs commit: parrot/imcc imcc.l
At 08:44 PM 1/9/2004 +, Harry Jackson wrote: Melvin Smith wrote: But, if you want macros to stay, let them stay. So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. I think we are going to have an alternative to C.constant builtin to IMCC, the best suggestion seems to be C.define As far as macros, I guess we will keep them for the near future. I think its time to create a new branch for imcc development, so lets see how things work out. It may be that we can keep them in some form. One thing to consider: when we put an API on top of IMCC, macros won't translate; they are only for the text version. -Melvin
Re: cvs commit: parrot/imcc imcc.l
At 07:36 PM 1/9/2004 +0100, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote: Which is why I hoped people would pitch in and help fix the tests. Its not tests only. There's already production code out there using Parrot - ask Dan or read his blog. And of course macros are used not only in tests, they are in library code and so on. Dan is smart enough not to arbitrarily update his tree with a current unstable CVS shapshot that is temporarily in flux. You don't update production code everytime a new revision appears in CVS. You wait until a release. In between releases, I would like to have opportunity to break things, honestly, while we are still in the alpha stage. This is alpha code, and my approach is to do what needs to be done and force us to deal with it sooner than later. That's ok. But we also had some priorities nailed down. First is to fix current bugs and to finally implement the pdd03 changes. I know, that one bug is related to macros, but changing the generated labels from line-numbers to an incremented counter wil very likely fix that too. I understand, but in real life I might get time to work on a small mod, and large mods sometimes have to wait for a larger coding window. I think its time we create a branch for imcc2 mods. That way we can work in parallel on these things at a more granular pace and not affect Parrot for extended periods of time. We can then backpatch some of the changes as soon as they work rather than waiting to merge the branch (such as dup labels and PCC stuff) but the branch will be available for people to experiment with. I'll create the branch as soon as I get some significant stuff to commit, maybe this weekend. -Melvin
