Smalltalk › Pharo › Pharo Smalltalk Users

CodeGenerator, your opinions?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

30 messages Options

kilon.alios

Re: CodeGenerator, your opinions?

I would not hold my breath if I were you for 3 reasons

1) this idea will go through only if my direct bridge via shared memory between Pharo and Unreal fails are is proven very limited, which I highly doubt.

2) even if I proceed with it, I will certainly be specialised for Unreal and have little interest in covering C++, huge and ugly syntax. So it will probably be just a few steps further than CCodeGenerator than a full implementation.

3) I am interested in producing readable C++ code, which makes this project even harder

long term though I could proceed with this anyway if I deem it useful under specific scenarios.

To really make this tempting for C++ coders would need a full implementation.

But in any case as I said, its very low priority for me, just a worse case scenario that I would try to avoid as much as I can.

On Tue, Oct 18, 2016 at 6:03 PM Hernán Morales Durand <[hidden email]> wrote:

Hi Dimitris,

That would be certainly nice. C++ is hard, but if one start with a basic instantiation template it could be easier to move forward to more complex tasks like mapping data structures to STL, their containers and iterators. And I think it would attract C++ developers to Smalltalk.
Cheers,

Hernán

2016-10-18 4:54 GMT-03:00 Dimitris Chloupis <[hidden email]>:
There is the CCodeGenerator , which is basically Slang, Smalltalk that is turned into basic C. I would like to expand it to generate C++ at some point for converting pharo code to C++ code that I will be able to add to Unreal. Though its a very low priority project for me.

http://smalltalkhub.com/#!/~PavelKrivanek/CCodeGenerator

Personally I am against generalized solutions because they tend to be bad for specialized cases , on the other hand I welcome any code that I can use as inspiration for my own code generator.

On Tue, Oct 18, 2016 at 8:25 AM Hernán Morales Durand <[hidden email]> wrote:
Hi guys,

I am writing a code generator, doing a few iterations right now.
I want your opinion, which most useful thing would you like to be generated automatically? It could be a pattern, an idiom, another language...

For example my own wish (roadmap) list:

- A "settings framework" settings class generator.
- A state machine generator (based in the excellent paper of Trevor P. Hopkins)
- A Spec UI generator.

Let me know your thoughts.

Cheers,

Hernán

otto

Re: CodeGenerator, your opinions?

In reply to this post by hernanmd

> Do you mean internal or embedded DSL? I am open to write an DSL if
> facilitates the job, the thing with the Trevor's paper is that he defines 6
> implementations of FSM's (and in each implementation he considers several
> issues leading to sub-implementations) so I would like a DSL which let me
> express different implementations for the same FSM. Plus there are FSM
> implementations out there: HotDraw, Connectors, MIDIInputParser, XMIReader,
> SState, etc. I think a "correct" DSL would enable to define any of them
> right?

I just meant some syntactically terse way of expressing a state
machine so that one can see the logic clearly. Representing a state
machine in a graphical way is ideal. We did this once, but the problem
is to make the state machine definition resilient to refactorings and
changes to the code. What I mean is that compiling something into code
is a one way thing; to keep it maintained, one would like to "reverse
compile" and draw the state machine from code.

A "correct" DSL would be something like a Harel state diagram, which
should be able to express most requirements.

I attach our state package, if you're interested. Not directly one of
the approaches in Trevor's paper. Perhaps another option. I would like
to extend it to use guards and actions and more.

> The approach I am using now is a parametrized code generator, using
> templates (not in the form of T4 templates), so it's a long way.
> Maybe Helvetia could help?

Out of my depth here; will have to read a lot more.

>
>
>>
>> On Tue, Oct 18, 2016 at 9:29 AM, Julien Delplanque <[hidden email]>
>> wrote:
>> > Hello,
>> >
>> > A generator for the visitor design pattern:
>> > - Generate methods in visited objects: VisitedObject>>#accept: (with the
>> > selector name configurable)
>> > - Generate empty methods (or methods with a "self
>> > subclassResponsability" if
>> > an abstract visitor is generated)
>> > called in #accept: methods of VisitedObjects in the Visitor i.e
>> > Visitor>>#acceptVisitedObject: (with the selector
>> > name configurable again).
>> >
>> > Each time this design pattern has to be used, it is annoying to write by
>> > hand all these methods.
>> >
>> > Regards,
>> >
>> > Julien
>> >
>> >
>> > On 18/10/16 07:24, Hernán Morales Durand wrote:
>> >>
>> >> Hi guys,
>> >>
>> >> I am writing a code generator, doing a few iterations right now.
>> >> I want your opinion, which most useful thing would you like to be
>> >> generated
>> >> automatically? It could be a pattern, an idiom, another language...
>> >>
>> >> For example my own wish (roadmap) list:
>> >>
>> >> - A "settings framework" settings class generator.
>> >> - A state machine generator (based in the excellent paper of Trevor P.
>> >> Hopkins)
>> >> - A Spec UI generator.
>> >>
>> >> Let me know your thoughts.
>> >>
>> >> Cheers,
>> >>
>> >> Hernán
>> >>
>> >
>> >
>>
>

Wonka-StateTransition-Core-otto.1645.mcz (5K) Download Attachment

Wonka-StateTransition-Tests-Core-otto.4385.mcz (3K) Download Attachment

otto

Re: CodeGenerator, your opinions?

Sorry, I see there are some unresolved dependencies on our code. Let
me know if I should work on that.

On Wed, Oct 19, 2016 at 5:44 AM, Otto Behrens <[hidden email]> wrote:

>> Do you mean internal or embedded DSL? I am open to write an DSL if
>> facilitates the job, the thing with the Trevor's paper is that he defines 6
>> implementations of FSM's (and in each implementation he considers several
>> issues leading to sub-implementations) so I would like a DSL which let me
>> express different implementations for the same FSM. Plus there are FSM
>> implementations out there: HotDraw, Connectors, MIDIInputParser, XMIReader,
>> SState, etc. I think a "correct" DSL would enable to define any of them
>> right?
>
> I just meant some syntactically terse way of expressing a state
> machine so that one can see the logic clearly. Representing a state
> machine in a graphical way is ideal. We did this once, but the problem
> is to make the state machine definition resilient to refactorings and
> changes to the code. What I mean is that compiling something into code
> is a one way thing; to keep it maintained, one would like to "reverse
> compile" and draw the state machine from code.
>
> A "correct" DSL would be something like a Harel state diagram, which
> should be able to express most requirements.
>
> I attach our state package, if you're interested. Not directly one of
> the approaches in Trevor's paper. Perhaps another option. I would like
> to extend it to use guards and actions and more.
>
>> The approach I am using now is a parametrized code generator, using
>> templates (not in the form of T4 templates), so it's a long way.
>> Maybe Helvetia could help?
>
> Out of my depth here; will have to read a lot more.
>
>>
>>
>>>
>>> On Tue, Oct 18, 2016 at 9:29 AM, Julien Delplanque <[hidden email]>
>>> wrote:
>>> > Hello,
>>> >
>>> > A generator for the visitor design pattern:
>>> > - Generate methods in visited objects: VisitedObject>>#accept: (with the
>>> > selector name configurable)
>>> > - Generate empty methods (or methods with a "self
>>> > subclassResponsability" if
>>> > an abstract visitor is generated)
>>> > called in #accept: methods of VisitedObjects in the Visitor i.e
>>> > Visitor>>#acceptVisitedObject: (with the selector
>>> > name configurable again).
>>> >
>>> > Each time this design pattern has to be used, it is annoying to write by
>>> > hand all these methods.
>>> >
>>> > Regards,
>>> >
>>> > Julien
>>> >
>>> >
>>> > On 18/10/16 07:24, Hernán Morales Durand wrote:
>>> >>
>>> >> Hi guys,
>>> >>
>>> >> I am writing a code generator, doing a few iterations right now.
>>> >> I want your opinion, which most useful thing would you like to be
>>> >> generated
>>> >> automatically? It could be a pattern, an idiom, another language...
>>> >>
>>> >> For example my own wish (roadmap) list:
>>> >>
>>> >> - A "settings framework" settings class generator.
>>> >> - A state machine generator (based in the excellent paper of Trevor P.
>>> >> Hopkins)
>>> >> - A Spec UI generator.
>>> >>
>>> >> Let me know your thoughts.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Hernán
>>> >>
>>> >
>>> >
>>>
>>

jfabry

Re: CodeGenerator, your opinions?

In reply to this post by otto

Sorry, I did not catch this thread before.

If you are looking for a terse way to describe state machines, you may want to have a look at LRP, a live programming language for nested state machines (for robotics), implemented in Pharo. It seems to have what you are talking about in your mail. It is made for robotics, but in the end can be used for a lot more stuff since it has a clean integration with Pharo.

The URL of LRP is http://pleiad.cl/LRP If you have any questions, feel free to ask!

--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

> On 19 Oct 2016, at 00:44, Otto Behrens <[hidden email]> wrote:
>
> I just meant some syntactically terse way of expressing a state
> machine so that one can see the logic clearly. Representing a state
> machine in a graphical way is ideal. We did this once, but the problem
> is to make the state machine definition resilient to refactorings and
> changes to the code. What I mean is that compiling something into code
> is a one way thing; to keep it maintained, one would like to "reverse
> compile" and draw the state machine from code.
>
> A "correct" DSL would be something like a Harel state diagram, which
> should be able to express most requirements.

stepharo

Re: CodeGenerator, your opinions?

In reply to this post by hernanmd

Le 18/10/16 à 07:24, Hernán Morales Durand a écrit :

> Hi guys,
>
> I am writing a code generator, doing a few iterations right now.
> I want your opinion, which most useful thing would you like to be
> generated automatically? It could be a pattern, an idiom, another
> language...
>
> For example my own wish (roadmap) list:
>
> - A "settings framework" settings class generator.
> - A state machine generator (based in the excellent paper of Trevor P.
> Hopkins)

> - A Spec UI generator.
That one
and a FAMIX Metamodel. Brice should build one so may be he can use yours
and extend it.

>
> Let me know your thoughts.
>
> Cheers,
>
> Hernán
>

stepharo

Re: CodeGenerator, your opinions?

In reply to this post by hernanmd

Hernan

What is the input you take to generate magritte?

Lionel would like to have a kind of Crud on top of Pharo and it would be good for business.

Stef

Le 18/10/16 à 18:07, Hernán Morales Durand a écrit :

2016-10-18 9:35 GMT-03:00 Lionel Akue <[hidden email]>:

Great!

We had the same idea :)

Let me know if we can join forces to speed uo things.

The first requirements I wrote was to generate Spec UI directly. But I rather chose to make Magritte compatible with Spec.

So from the Magritte description, we could generate Spec, Seaside ...

The CodeGenerator I wrote already generates Magritte code. If you load it in Pharo 5

Gofer it
    smalltalkhubUser: 'hernan' project: 'CodeGenerator';
    configuration;
    loadDevelopment.

Have a look at the usage examples:

#exampleMagritteDescriptionCreation1
#exampleMagritteDescriptionCreation2
#exampleMagritteDescriptionCreation3

If you have suggestions I would like to read.

Hernán

Lionel

2016-10-18 14:20 GMT+02:00 Peter Uhnak <[hidden email]>:

Hi Hernan,

I wrote some time ago two basic code generators (both in Pharo) from UML-ified FAMIX for a particular user (so there are some domain-specific patterns),
one for Pharo syntax ( https://github.com/OpenPonk/class-editor/blob/master/docs/code-generation/uml-to-code.md )
and one for VW syntax ( https://github.com/OpenPonk/class-editor/blob/master/docs/vw-code-generation/pim-psm.md )

(the code is here https://github.com/OpenPonk/class-editor/tree/master/repository/DynaCASE-Generator.package and here https://github.com/OpenPonk/class-editor/tree/master/repository/UML-CodeGenerator.package )

The most pain I had was with expressing templateable code to which I could just plug specific data, I wanted to look at QVT but didn't have the time yet.
But it would be interesting to see if your generator could address such issues; plus soon I want to iterate on my generators to have more live interaction (so the code is generated on the fly as the model is created, although I am using Pharo Refactoring engine for now, which is also quite powerful.)

Addionally, Lionel (in cc) is working on some meta system generating classes with magritte descriptions.

So it would be cool if we could have some really cool generator that could do many cool things. :)

Peter

On Tue, Oct 18, 2016 at 02:24:28AM -0300, Hernán Morales Durand wrote:
> Hi guys,
>
> I am writing a code generator, doing a few iterations right now.
> I want your opinion, which most useful thing would you like to be generated
> automatically? It could be a pattern, an idiom, another language...
>
> For example my own wish (roadmap) list:
>
> - A "settings framework" settings class generator.
> - A state machine generator (based in the excellent paper of Trevor P.
> Hopkins)
> - A Spec UI generator.
>
> Let me know your thoughts.
>
> Cheers,
>
> Hernán

stepharo

Re: CodeGenerator, your opinions?

In reply to this post by Evan Donahue

Looks fun :)

Le 18/10/16 à 19:10, Evan Donahue a écrit :

So this isn't a specific out-of-the-box solution to any of the
code-generation use cases people have been discussing, but I thought it was
relevant enough to toss it out there.

I'm currently doing some work on program synthesis using a Pharo port of the
miniKanren logic programming language (http://minikanren.org/). The Pharo
version is here: http://smalltalkhub.com/#!/~EvanDonahue/SmallKanren . 

So far, I've only used it to implement this paper on generating scheme
programs (http://smalltalkhub.com/#!/~EvanDonahue/SmallKanren), the
implementation of which is here:
http://smalltalkhub.com/#!/~EvanDonahue/Barliman . 

I've thought a bit about things like generating GUI's, and it seems like
something interesting could be done there, since you could imagine feeding
it constraints and then giving the results a thumbs up/thumbs down to see
other satisfying layouts more or less like the ones you voted on, but the
probabilistic learning component is an object of current research and isn't
ready yet. 

I was planning on sending out an announcement once it was more complete and
robust, as right now it has lots of tests but not much documentation, and
the architecture is changing rapidly, per research requirements, but if
anyone is interested in knowing more about it feel free to get in touch.
This is part of a broader research program on intelligent interfaces, so
hopefully some cooler things come out of it later down the line.

Cheers,
Evan

stepharo

Re: CodeGenerator, your opinions?

In reply to this post by philippeback

would be nice to ask dragos his Smalltalk code :)

Le 18/10/16 à 21:20, [hidden email] a écrit :

http://www.micro-workflow.com/PDF/wecfo.pdf seemed interesting.

Not state machines per se but still.

Longer paper here: http://micro-workflow.com/PDF/phdthesis.pdf

Phil

On Tue, Oct 18, 2016 at 8:47 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:

Implementing State Machines in Smalltalk (1993) Trevor Hopkins
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.6732

- A state machine generator (based in the excellent paper of Trevor P. Hopkins)

i add it to my reading list. thanks

--

Bernardo E.C.

Sent from a cheap desktop computer in South America.

hernanmd

Re: CodeGenerator, your opinions?

In reply to this post by stepharo

Hi Stef

2016-10-19 17:29 GMT-03:00 stepharo <[hidden email]>:

Hernan

What is the input you take to generate magritte?

Something like this:

    CGStMagritte uniqueInstance
        inputClass: ModelClass1;
        targetClass: ModelClass1;
        setBooleanAttributes: 'instVar1'         label: 'label iVar1' priority: 10;
        setDateAndTimeAttributes: 'instVar2' label: 'label Date and Time' priority: 20;
        setDateAttributes: 'instVar3'             label: 'label Date' priority: 30;
        setFileAttributes: 'iVarFile'             label: 'label File' priority: 40;
        setMemoAttributes: 'iVarMemo'             label: 'label Memo' priority: 50;
        setMultiOptionAttributes: 'iVarMultiOption' label: 'label Multi Option' priority: 60;
        setNumberAttributes: 'iVarInteger'     label: 'label Integer' priority: 70;
        generateMethods.
    Smalltalk tools browser openOnClass: ModelClass1.
    self inform: 'Done'.

which generates

ModelClass1>>descriptionInstVar1
    <magitteDescription>
    | tmp2 |
    tmp2 := MABooleanDescription new.
    tmp2
        accessor: #instVar1;
        label: 'label iVar1';
        priority: 10.
    ^ tmp2 yourself

ModelClass1>>descriptionInstVar2
    <magitteDescription>
    | tmp2 |
    tmp2 := MADateAndTimeDescription new.
    tmp2
        accessor: #instVar2;
        label: 'label Date and Time';
        priority: 20.
    ^ tmp2 yourself

and so on.

Lionel would like to have a kind of Crud on top of Pharo and it would be good for business.

Cool, hope he finds useful the code generator

Stef

Le 18/10/16 à 18:07, Hernán Morales Durand a écrit :

2016-10-18 9:35 GMT-03:00 Lionel Akue <[hidden email]>:

Great!

We had the same idea :)

Let me know if we can join forces to speed uo things.

The first requirements I wrote was to generate Spec UI directly. But I rather chose to make Magritte compatible with Spec.

So from the Magritte description, we could generate Spec, Seaside ...

The CodeGenerator I wrote already generates Magritte code. If you load it in Pharo 5

Gofer it
    smalltalkhubUser: 'hernan' project: 'CodeGenerator';
    configuration;
    loadDevelopment.

Have a look at the usage examples:

#exampleMagritteDescriptionCreation1
#exampleMagritteDescriptionCreation2
#exampleMagritteDescriptionCreation3

If you have suggestions I would like to read.

Hernán

Lionel

2016-10-18 14:20 GMT+02:00 Peter Uhnak <[hidden email]>:

Hi Hernan,

I wrote some time ago two basic code generators (both in Pharo) from UML-ified FAMIX for a particular user (so there are some domain-specific patterns),
one for Pharo syntax ( https://github.com/OpenPonk/class-editor/blob/master/docs/code-generation/uml-to-code.md )
and one for VW syntax ( https://github.com/OpenPonk/class-editor/blob/master/docs/vw-code-generation/pim-psm.md )

(the code is here https://github.com/OpenPonk/class-editor/tree/master/repository/DynaCASE-Generator.package and here https://github.com/OpenPonk/class-editor/tree/master/repository/UML-CodeGenerator.package )

The most pain I had was with expressing templateable code to which I could just plug specific data, I wanted to look at QVT but didn't have the time yet.
But it would be interesting to see if your generator could address such issues; plus soon I want to iterate on my generators to have more live interaction (so the code is generated on the fly as the model is created, although I am using Pharo Refactoring engine for now, which is also quite powerful.)

Addionally, Lionel (in cc) is working on some meta system generating classes with magritte descriptions.

So it would be cool if we could have some really cool generator that could do many cool things. :)

Peter

On Tue, Oct 18, 2016 at 02:24:28AM -0300, Hernán Morales Durand wrote:
> Hi guys,
>
> I am writing a code generator, doing a few iterations right now.
> I want your opinion, which most useful thing would you like to be generated
> automatically? It could be a pattern, an idiom, another language...
>
> For example my own wish (roadmap) list:
>
> - A "settings framework" settings class generator.
> - A state machine generator (based in the excellent paper of Trevor P.
> Hopkins)
> - A Spec UI generator.
>
> Let me know your thoughts.
>
> Cheers,
>
> Hernán

hernanmd

Re: CodeGenerator, your opinions?

In reply to this post by otto

Thank you Otto,

I had a look and it seems a nice implementation (couldn't load into the image but using the Monticello Browser)

Cheers,

Hernán

2016-10-19 0:44 GMT-03:00 Otto Behrens <[hidden email]>:

> Do you mean internal or embedded DSL? I am open to write an DSL if
> facilitates the job, the thing with the Trevor's paper is that he defines 6
> implementations of FSM's (and in each implementation he considers several
> issues leading to sub-implementations) so I would like a DSL which let me
> express different implementations for the same FSM. Plus there are FSM
> implementations out there: HotDraw, Connectors, MIDIInputParser, XMIReader,
> SState, etc. I think a "correct" DSL would enable to define any of them
> right?

I just meant some syntactically terse way of expressing a state
machine so that one can see the logic clearly. Representing a state
machine in a graphical way is ideal. We did this once, but the problem
is to make the state machine definition resilient to refactorings and
changes to the code. What I mean is that compiling something into code
is a one way thing; to keep it maintained, one would like to "reverse
compile" and draw the state machine from code.

A "correct" DSL would be something like a Harel state diagram, which
should be able to express most requirements.

I attach our state package, if you're interested. Not directly one of
the approaches in Trevor's paper. Perhaps another option. I would like
to extend it to use guards and actions and more.

> The approach I am using now is a parametrized code generator, using
> templates (not in the form of T4 templates), so it's a long way.
> Maybe Helvetia could help?

Out of my depth here; will have to read a lot more.

>
>
>>
>> On Tue, Oct 18, 2016 at 9:29 AM, Julien Delplanque <[hidden email]>
>> wrote:
>> > Hello,
>> >
>> > A generator for the visitor design pattern:
>> > - Generate methods in visited objects: VisitedObject>>#accept: (with the
>> > selector name configurable)
>> > - Generate empty methods (or methods with a "self
>> > subclassResponsability" if
>> > an abstract visitor is generated)
>> > called in #accept: methods of VisitedObjects in the Visitor i.e
>> > Visitor>>#acceptVisitedObject: (with the selector
>> > name configurable again).
>> >
>> > Each time this design pattern has to be used, it is annoying to write by
>> > hand all these methods.
>> >
>> > Regards,
>> >
>> > Julien
>> >
>> >
>> > On 18/10/16 07:24, Hernán Morales Durand wrote:
>> >>
>> >> Hi guys,
>> >>
>> >> I am writing a code generator, doing a few iterations right now.
>> >> I want your opinion, which most useful thing would you like to be
>> >> generated
>> >> automatically? It could be a pattern, an idiom, another language...
>> >>
>> >> For example my own wish (roadmap) list:
>> >>
>> >> - A "settings framework" settings class generator.
>> >> - A state machine generator (based in the excellent paper of Trevor P.
>> >> Hopkins)
>> >> - A Spec UI generator.
>> >>
>> >> Let me know your thoughts.
>> >>
>> >> Cheers,
>> >>
>> >> Hernán
>> >>
>> >
>> >
>>
>