On Wed, Aug 5, 2015 at 4:18 PM, David Mertens <[email protected]>
wrote:
> Hey Chris,
>
> Sorry, some of my responses above are a bit surly.
>
Not to worry. I generally try to assume good will in postings---regardless
as how things can come across in language/word choice/emphasis. I
also hope others will do the same favor for me. :-)
> We should think of C::Blocks as a front-end to libtcc with highly
> sophisticated symbol table management. Although we might use C::Blocks to
> prototype PDL JIT stuff, we almost certainly should expect to hook directly
> into libtcc ourselves. Since libtcc with extended symbol table support is
> distributed via Alien::TinyCCx, we should be able to get that working for
> all sorts of PDLs for all sorts of Perl versions.
>
Thanks for clearing that up. If I could build TinyCC on cygwin or
could use Alien::TinyCCx there I might have already realized that
myself.
> As for object-oriented stuff, I have begun to realize that we will need to
> keep track of object and class properties at the Perl level, i.e. we need
> some sort of object system or meta-object protocol. Tracking this at the C
> level is likely to be too daunting. Rather than re-invent the wheel, I
> believe we can make use of Moose's Class::MOP. We would need to subclass
> things like Class::MOP::Attribute and Class::MOP::Method so that they know
> how to construct vtables and struct layouts, and so they know how to work
> with C types and code. If we use XS::Object::Magic, then we will not have
> too much trouble using a hashref for the basic Perl-level reference,
> something that I *really* like about Prima.
>
I'm hoping that the new PDL3 implementation can offer symmetric
access from both C and Perl code. By using the C Object System
which sivoais pointed me to:
http://ldeniau.web.cern.ch/ldeniau/cos.html
http://github.com/CObjectSystem/COS
we get a C library that support an OOP model with MetaClass
support. The object model is different from C++ with inspiration
drawn from Objective C and CLOS (the Common Lisp Object
System). However, it is very general and I believe it can support
a C layer version of Moo---sort of like an electrostatic image
charge (called Coo?). It uses the CPP to generate the code
from the C source file and builds the code using some shell
scripts to handle the processing.
For perl/PDL3 work, it would make sense to use perl to
drive the build process for ease of use. For me, a very
attractive feature is that it is independent of perl. This is
needed to support the use case of PDL routines being
created at either the C or perl level and being called from
either the C or perl level. This could allow PDL to be used
from any "C friendly" application or environment.
Cheers,
Chris
> So, that's my 2 cents for the moment on that bit.
> David
>
> On Wed, Aug 5, 2015 at 3:32 PM, Chris Marshall <[email protected]>
> wrote:
>
>> Hi David-
>>
>> Per my response to Joel, I think the basic improved PDL::PP::JIT
>> support could be done in a simple but clunky way using a basic
>> libtcc interface. The legacy perls could still have the benefits of
>> new JIT compiling while the modern perls could be C::Blocks based.
>>
>> I haven't yet gotten tcc to build on cygwin but I look forward to trying
>> out your code when I get a working tcc.
>>
>> Cheers,
>> Chris
>>
>> On Wed, Aug 5, 2015 at 1:24 PM, David Mertens <[email protected]>
>> wrote:
>>
>>> Hey Chris,
>>>
>>> Another idea occurred to me. If you absolutely need v5.10 supported,
>>> somebody (i.e. not me) could probably hack something together with
>>> Devel::Declare. This would make it possible to use the same interface, and
>>> would work for Perls all the way back to v5.8.1. I am skeptical about how
>>> well it would handle some of the most important features of C::Blocks,
>>> however, such as lexical scoping of shared C libraries. This would not be a
>>> small undertaking.
>>>
>>> David
>>>
>>> On Wed, Aug 5, 2015 at 12:21 PM, David Mertens <[email protected]
>>> > wrote:
>>>
>>>> Yes, it absolutely requires the keyword API to work.
>>>>
>>>> From the Perl side, it builds and inserts OPs, and it checks the local
>>>> compiling context for lexically scoped variables. These can only be done by
>>>> "breaking" into the Perl parser, hence the keyword API.
>>>>
>>>> From the TCC side, TCC uses a lot of globals, setting them up during
>>>> TCCState construction. This means you cannot have multiple active
>>>> compilation units at the same time. Keywords let me enforce one state at a
>>>> time merely by code layout, in a way that is completely obvious to a user,
>>>> letting me hide all of this.
>>>>
>>>> It may be possible to write a C::Blocks library that exposes the libtcc
>>>> API, in which case you would be able to build your own compiler states and
>>>> manage extended symbol tables. Or, if you just want normal TCC, just use
>>>> XS::TCC, C::TinyCompiler, or FFI::TinyCC.
>>>>
>>>> David
>>>>
>>>> On Tue, Aug 4, 2015 at 8:39 PM, Chris Marshall <[email protected]>
>>>> wrote:
>>>>
>>>>> Does C::Blocks really require the perl keyword API to work?
>>>>> It would be nice if there was a version that could work with
>>>>> perl 5.10.x.
>>>>>
>>>>> --Chris
>>>>>
>>>>>
>>>>>
>>
>
>
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." -- Brian Kernighan
>
------------------------------------------------------------------------------
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
