Re: A question for DLLCC users (and potential users)

>
> If the answer is that yes, the tools can be assumed, then a number of
> things become a lot easier and more reliable.
>
Well given you're pushing to create your own C building infrastructure,
I don't see why you can't make that the assumption of your approach. I
think it's a reasonable assumption that if you intend to -parse- header
files, you're likely to have an SDK installed which basically means you
have tools.

Michael

Antony Blakey wrote: In that case - I'd be fine with the expectation that I'll have tools on
my machine - so long as you tell me which ones I need and how to get
them :).

Michael

Antony Blakey schrieb am 15.09.2007 05:59:
> Is it reasonable to assume that if you are building an interface to a
> library on a given platform, then you will have some form of development
> tools installed on that platform? Specifically, a C pre-processor and
> compiler, or maybe a C++ compiler if you are interfacing to C++
> libraries. I'm not talking about a) requiring the installation of some
> other tool such as gcc-xml; nor b) requiring those tools at runtime; nor
> c) building stubs that you would need to ship.

I am not writing external interfaces very often, but so far I have never
had the need for C/C++ development tools. The binary libraries and the
header files were all I needed, as DLLCC has its own parser for header
files. For interfacing to MS Windows libraries, all I had was the
documentation at MSDN, and I wrote the interface methods manually.

> I think it's a reasonable assumption that parsing C headers for some
> library will at least require a platform SDK i.e. platform/clib headers,
> but I'm not as sure about the tools.

Sometimes you don't even need a platform SDK, as in the case of Windows
libraries.

> If the answer is that yes, the tools can be assumed, then a number of
> things become a lot easier and more reliable.

Here I agree with Michael Lucas-Smith: If you document what tools one
needs and how to use them in the process, that's fine. It would only
make a difference if the tools cost so much money that buying them is
prohibitive. Or if using them is so complicated for non-experts that
they'd rather use DLLCC in its current incarnation instead. :-)

Best regards,
Joachim Geidel

If I want to interface with a third-party library from within Smalltalk,
I want to do that without necessarily having to install a C system on my
machine.  Right now, I interface with a third-party graphics library to
create on-demand display charts, due to the limitations of the Business
Graphics subsystem (which hasn't been updated in years and is basically
worthless).  

 
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

The requirement for tools would be at the time you make the interface,
not the time of using the interface - as I understand it.

Michael

Sattler, Thomas (IT) wrote:

Thomas,

You can have a look at EyeSee which is in the public store and here:

http://smallwiki.unibe.ch/moose/tools/eyesee/

Notice that up to 9/11 Tudor was working on the Widgetry version ?

They also have there own store with public acces.

@+Maarten,


Sattler, Thomas (IT) a écrit :

If I want to interface with a third-party library from within Smalltalk,
I want to do that without necessarily having to install a C system on my
machine.  Right now, I interface with a third-party graphics library to
create on-demand display charts, due to the limitations of the Business
Graphics subsystem (which hasn't been updated in years and is basically
worthless).  

 

  

-----Original Message-----
From: [hidden email] 
[[hidden email]] On Behalf Of Antony Blakey
Sent: Saturday, September 15, 2007 12:00 AM
To: VWDEV List; vwnc
Subject: A question for DLLCC users (and potential users)


Comrades,
          In the process of building replacements for some of 
the DLLCC infrastructure, I've come to to a key design point. 
I'm hoping to get some feedback.

Is it reasonable to assume that if you are building an 
interface to a library on a given platform, then you will 
have some form of development tools installed on that 
platform? Specifically, a C pre- processor and compiler, or 
maybe a C++ compiler if you are interfacing to C++ libraries. 
I'm not talking about a) requiring the installation of some 
other tool such as gcc-xml; nor b) requiring those tools at 
runtime; nor c) building stubs that you would need to ship.

I think it's a reasonable assumption that parsing C headers 
for some library will at least require a platform SDK i.e. 
platform/clib headers, but I'm not as sure about the tools.

If the answer is that yes, the tools can be assumed, then a 
number of things become a lot easier and more reliable.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

What can be done with fewer [assumptions] is done in vain with more
   -- William of Ockham (ca. 1285-1349)




    

--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.



  

Hi,

If you want to use EyeSee, you can get it by loading  
EyeSeeDevelopment and all its prerequisites from the Public Store. If  
you want to peek at the latest development stage you can also connect  
to our Store:
http://smallwiki.unibe.ch/moose/faq/connecttoscgstore/

We are still working on the Widgetry version of a new browser for  
Moose and in this context we also got EyeSee working with Widgetry.

We are certainly working to release the browser using Widgetry, but  
we are still to assess whether we are going to pursue Widgetry  
further. The decision is a bit difficult :)
- on the one hand we are told to use a framework we couldn't easily  
work with the past years, and
- on the other hand we are told that the one framework we could get  
along with will not go any further.

Cheers,
Doru


On Sep 15, 2007, at 6:50 PM, Maarten Mostert wrote:

--
www.iam.unibe.ch/~girba
www.iam.unibe.ch/~girba/blog/

"Beauty is where we see it."

From: Joachim Geidel [mailto:[hidden email]]
Same here. But the first time(s) I wanted to build an external
interface, I tried to use the VW C parser and was confused, then
disappointed.

If there has to be an external development tool, I'd prefer a simple
download and install - even if it means the tool isn't well known or
much use otherwise.

Steve

On 18/09/2007, at 8:31 AM, <[hidden email]> wrote:

> Whatever you do, have a UI available to for it.

I appreciate your point, but the issue is that the process of  
reflecting over the semantic model of the imported code is  
fundamentally programatic, and the transformations you do to the  
model can't be expressed as a UI.

When I say script, what I mean is that each import task requires a  
class to be created that represents that task. This project is  
actually more about reifying and reflecting over C declarations, with  
a side effect being that it can generate DLLCC methods. The per-task  
import class has methods that, amongst other things:

1. Generate the text that is processed e.g.

FUSEInterfaceBuilder>>sourceText
        ^'#define _FILE_OFFSET_BITS 64
#define FUSE_USE_VERSION 26
#include "fuse/fuse.h"
#include "fuse/fuse_lowlevel.h"
#include <sys/mount.h>
#include <sys/types.h>
#include <pwd.h>
#include <errno.h>'

2. Control the model transformation e.g.

FUSEInterfaceBuilder>>transformModel
        super transformModel.
        self resolveAllPrivateTypedefs
        self convertPointerToFunctionFieldsIntoTypedefs.
        self eliminateBitfields.
        self createErrnoEnumeration

3. Actually do custom transformations e.g.

FUSEInterfaceBuilder>>eliminateBitfields
        "This really is a horrible thing, and wouldn't be required if DLLCC  
did bitfields"
        | ffi |
        ffi := model rootNamespace memberAt: 'fuse_file_info'.
        "Setting the context to nil will remove the field from it's parent"
        1 to: 3
                do:
                        [:i |
                        | f |
                        f := ffi members at: 4.
                        model elements removeKey: f id.
                        f context: nil].
        (ffi members at: 4) bits: 32

FUSEInterfaceBuilder>>createErrnoEnumeration
        "Create an enumeration from #defines"
        | errnoDefines enum |
        enum := Seaweed.Enumeration new name: 'ErrorCode'.
        enum context: model rootNamespace.
        model addElement: enum.
        errnoDefines := model defines select: [:d | d name hasPrefix: 'E'].
        errnoDefines do:
                        [:d |
                        enum values at: d name put: d value.
                        d shouldGenerate: false]


Someone else might do a UI, but Wrapper is fundamentally not a VW  
skill I have, and given that I've already scratched my itch on this  
project and everything I'm doing now is unmotivated by any  
requirement other than to advance the state of VW, (and Wrapper sans  
UIBuilder isn't well documented), it's not likely a skill I'll acquire.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Success is not the key to happiness. Happiness is the key to success.
  -- Albert Schweitzer

BTW, for those curious why one would want gccxml to properly parse  
headers and why I'm even asking this question ...

I came across this type of code while processing (I think) FUSE for  
Linux:

   enum {
     value1 = 1,
   #define VALUE1 value1
     value2 = 2,
   #define VALUE2 value2
     value3 = 3
   #define VALUE3 value3
   }

While this example is simple, it can be considerably more involved.  
However, for all of the libraries I've dealt with, where I want to  
import scalar #defines, then by generating the following for the  
selected defines:

   extern void* dllcc_VALUE1 = (void*) VALUE1;
   extern void* dllcc_VALUE2 = (void*) VALUE2;
   extern void* dllcc_VALUE3 = (void*) VALUE3;

and running it through gccxml, I get fully resolved scalar values for  
each #define - initializer evaluation is one cool thing about gccxml.  
Hence I don't need an expression evaluator, which greatly simplifies  
the task. It turns out that the same defines on OSX don't remap the  
enum values, but the above technique works regardless.

This may not work in all cases - I need more test input, but I think  
it can be heuristically managed.

This is just one example of where reusing existing tools and not  
insisting on 'Smalltalk all the way down' is an enormous win in terms  
of shipping something in a reasonable timeframe with reasonable  
effort. And more powerful to boot.

Another example is symbol versioning on Linux, which is currently  
broken in DLLCC (basically you can't use dlysm), and requires some  
interaction with the target platform's bintools to extract versioning  
information from the libraries at import time (not runtime).

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The difference between ordinary and extraordinary is that little extra.

On 19/09/2007, at 2:09 AM, <[hidden email]>  
<[hidden email]> wrote:

> I guess I'd have to look at it a bit more, but it seems to me that  
> most
> of what you are putting in that class (that represents a task in the
> script) or script can and should be reflected in a UI.  Code  
> generation
> is easy enough.  I guess I'm volunteering to look into it - in my
> copious amounts of spare time, of course!

Excellent, thanks! I've just got my gccxml solution happening on  
Windows, I hope to publish a OSX/Linux/Windows validated solution  
shortly.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The intuitive mind is a sacred gift and the rational mind is a  
faithful servant. We have created a society that honours the servant  
and has forgotten the gift.
   -- Albert Einstein