Audrey Tang wrote:
Indeed, and I'd like to apologize publicly for the snipping.
Accepted and forgiven.
However, the re2c or regel-based scanner refactoring isn't different
from a "flex upgrade patch", as it (by definition) can't affect IMCC's
public API at all. An additional advantage is t
在 2006/7/18 上午 1:54 時，Audrey Tang 寫到：
If you have a way to make IMCC reentrant that involves upgrading
to a more recent version of flex and passing one additional
parameter, go for it! Send us a patch and if it passes all the
tests, we'll apply it.
As flex 2.5.30+ is not API compatible wi
在 2006/7/18 上午 1:21 時，Allison Randal 寫到：
LOL :) Audrey, I love you dear, but you always have an interesting
way of interpreting what I say. :)
Yes, I'm not willing to start a 6+ month project to gut IMCC. The
cost is too great and the benefit isn't great enough.
Indeed, and I'd like to ap
Audrey Tang wrote:
As I'm writing this, I noticed that Allison has ruled that we go with
PIR/PGE and eventually C-based libpge instead
-- since a lexer refactoring that doesn't affect the IMCC API will
somehow throw important projects on Parrot into a
"dead stall", and thread safety for PIR c
Vishal Soni wrote:
Allison this sounds great. To get started I will need some reference to
the OST format. Can you please point me in the right direction (some
documentation or sample code shall do.)?
Start with languages/punie/lib/POST/ and
languages/punie/lib/PIRGrammar.tg. This is the most
> Let's go for an agile, iterative approach to the spec. Write up some
> initial thoughts on the shape of the API and post them to
> parrot-porters. The group can do sanity-checking/brainstorming, and then
> you can start a prototype based on the result. After we've played with
> the prototype
Vishal Soni wrote:
Allison having said that we need an API for byte code generation that
supports plug n play optimizers would it make sense to start
implementing this layer. This API could be used for OST to byte code
generation. Later when Patrick's PGE to C parser generator is ready we
could
On Mon, 2006-07-17 at 14:49 -0700, Allison Randal wrote:
> re2c and lemon aren't enough of an improvement over flex and bison to be
> worth the pain of rewriting IMCC from scratch. If we do create a new way
> of producing bytecode (and it's a safe bet that we will at some point),
> I would lean
Vishal Soni wrote:
The current implementation is implemented using Flex and YACC. Flex
implementation has limitations in C mode. The C lexer generated by flex
cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in
C++ mode. This limition of flex will defeat the whole effort
