May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Macros?

by ClÃ©ment Bera

Just mentioning another use-case: getDatabaseInstance ^ (Production CifTrue: [Database] CifFalse: [MockDatabase]) new Since I use conditional compilation more often than just precompiling constants. I don't see an equivalent of asMethodConstant AST manipulation at runtime strategy in the image for this case right now but it's probably a couple lines of code with Reflectivity. On Sat, May 26, 2018 at 7:28 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > On Fri, May 25, 2018 at 10:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> >> On 25 May 2018, at 17:30, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> What about a preprocessor like the Java preprocessors ? The Truffle >> project relies heavily on that for high performance Java and it's quite >> nice. It's difficult to do that in Smalltalk right now. >> >> I think if you want to do what are asking for you just need to write a >> bytecode compiler extension. >> >> I did something similar in the past to have precomputed constants through >> AST manipulation at compilation time. You can find it here with examples: >> http://smalltalkhub.com/#!/~ClementBera/NeoCompiler. Once the code is >> loaded you need to recompile the examples (NeoCompilerExample >> withAllSubclassesDo: #compileAll.). With it you can write code such as: >> [ Smalltalk vm class ] Cvalue >> And depending if the compiler allowsPrecompilation or not, the bytecode >> compiler generates: >> Smalltalk vm class >> Or just a push literal with the precomputed value (the class >> VirtualMachine). >> >> >> this is not what #asMethodConstant provides? >> > > Can you turn asMethodConstant On and Off so you have the constant in > production and not a development time ? Typically at development time I > change the constants generated a lot and I don't want to waste time > recompiling all the time. > > But yeah, my project is from 2014. I guess instead of preprocessing you > could do everything at runtime with AST manipulation/recompilation like > in asMethodConstant. > > The main point of preprocessing IMO is to control performance, it's just > easier for me to just look at the generated bytecode and change the > preprocessor until it gets what I want, it's not always easy to run code > that will change your method at runtime quickly so you can look at the > bytecode generated. > > Anyway, I am not convinced at all something like that should be in the > base image. > > >> >> Esteban >> >> In the end I decided not to use this, but you can use it and extend it to >> support more than just constants (any AST manipulation is possible). >> Just checked it works in Pharo 6. >> >> On Fri, May 25, 2018 at 4:26 PM, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >> >>> Debiller 777 <ozovozovozo202(a)gmail.com> >>> wrote: >>> > Well, I've already asked about adding new literals to pharo or >>> Smalltalk in >>> > general, however this time I have a better idea: >>> > macros. Can they be added? Because if I understand correctly they may >>> be >>> > the only way to do that. >>> >>> Why do you think they would be a good idea? We have powerful >>> meta-programming facilities that are well understood and somewhat >>> supported >>> by tooling. How do we get value out of macros? >>> >>> Stephan >>> >>> >>> >>> >> >> >> -- >> ClÃ©ment BÃ©ra >> https://clementbera.github.io/ >> https://clementbera.wordpress.com/ >> >> >> > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ > https://clementbera.wordpress.com/ > -- ClÃ©ment BÃ©ra https://clementbera.github.io/ https://clementbera.wordpress.com/

May 26, 2018

Re: [Pharo-users] Macros?

by ClÃ©ment Bera

On Fri, May 25, 2018 at 10:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 25 May 2018, at 17:30, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > What about a preprocessor like the Java preprocessors ? The Truffle > project relies heavily on that for high performance Java and it's quite > nice. It's difficult to do that in Smalltalk right now. > > I think if you want to do what are asking for you just need to write a > bytecode compiler extension. > > I did something similar in the past to have precomputed constants through > AST manipulation at compilation time. You can find it here with examples: > http://smalltalkhub.com/#!/~ClementBera/NeoCompiler. Once the code is > loaded you need to recompile the examples (NeoCompilerExample > withAllSubclassesDo: #compileAll.). With it you can write code such as: > [ Smalltalk vm class ] Cvalue > And depending if the compiler allowsPrecompilation or not, the bytecode > compiler generates: > Smalltalk vm class > Or just a push literal with the precomputed value (the class > VirtualMachine). > > > this is not what #asMethodConstant provides? > Can you turn asMethodConstant On and Off so you have the constant in production and not a development time ? Typically at development time I change the constants generated a lot and I don't want to waste time recompiling all the time. But yeah, my project is from 2014. I guess instead of preprocessing you could do everything at runtime with AST manipulation/recompilation like in asMethodConstant. The main point of preprocessing IMO is to control performance, it's just easier for me to just look at the generated bytecode and change the preprocessor until it gets what I want, it's not always easy to run code that will change your method at runtime quickly so you can look at the bytecode generated. Anyway, I am not convinced at all something like that should be in the base image. > > Esteban > > In the end I decided not to use this, but you can use it and extend it to > support more than just constants (any AST manipulation is possible). > Just checked it works in Pharo 6. > > On Fri, May 25, 2018 at 4:26 PM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> Debiller 777 <ozovozovozo202(a)gmail.com> >> wrote: >> > Well, I've already asked about adding new literals to pharo or >> Smalltalk in >> > general, however this time I have a better idea: >> > macros. Can they be added? Because if I understand correctly they may be >> > the only way to do that. >> >> Why do you think they would be a good idea? We have powerful >> meta-programming facilities that are well understood and somewhat >> supported >> by tooling. How do we get value out of macros? >> >> Stephan >> >> >> >> > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ > https://clementbera.wordpress.com/ > > > -- ClÃ©ment BÃ©ra https://clementbera.github.io/ https://clementbera.wordpress.com/

May 26, 2018

Re: [Pharo-users] Macros?

by Esteban Lorenzano

> On 25 May 2018, at 17:30, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > What about a preprocessor like the Java preprocessors ? The Truffle project relies heavily on that for high performance Java and it's quite nice. It's difficult to do that in Smalltalk right now. > > I think if you want to do what are asking for you just need to write a bytecode compiler extension. > > I did something similar in the past to have precomputed constants through AST manipulation at compilation time. You can find it here with examples: http://smalltalkhub.com/#!/~ClementBera/NeoCompiler <http://smalltalkhub.com/#!/~ClementBera/NeoCompiler>. Once the code is loaded you need to recompile the examples (NeoCompilerExample withAllSubclassesDo: #compileAll.). With it you can write code such as: > [ Smalltalk vm class ] Cvalue > And depending if the compiler allowsPrecompilation or not, the bytecode compiler generates: > Smalltalk vm class > Or just a push literal with the precomputed value (the class VirtualMachine). this is not what #asMethodConstant provides? Esteban > In the end I decided not to use this, but you can use it and extend it to support more than just constants (any AST manipulation is possible). > Just checked it works in Pharo 6. > > On Fri, May 25, 2018 at 4:26 PM, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > Debiller 777 <ozovozovozo202(a)gmail.com <mailto:ozovozovozo202@gmail.com>> > wrote: > > Well, I've already asked about adding new literals to pharo or > Smalltalk in > > general, however this time I have a better idea: > > macros. Can they be added? Because if I understand correctly they may be > > the only way to do that. > > Why do you think they would be a good idea? We have powerful > meta-programming facilities that are well understood and somewhat supported > by tooling. How do we get value out of macros? > > Stephan > > > > > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ <https://clementbera.github.io/> > https://clementbera.wordpress.com/ <https://clementbera.wordpress.com/>

May 25, 2018

Re: [Pharo-users] [Pharo-dev] feenk log

by Norbert Hartl

Very impressive!! Hope Bloc and Brick move along to be included in pharo soon!! Norbert > Am 25.05.2018 um 13:30 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > We were a bit silent the last couple of months. Quite a bit happened in the meantime, so here is a summary (for more fine grained announcements, you can follow us on Twitter): > > ---- > Bloc > ---- > > - Scrolling. We finally have a good scrolling support: > https://twitter.com/feenkcom/status/991690465224331264 > This might sound like a trivial feature, but it turns out it is not. We had a bug that forced us to rethink the support quite deeply in order to be able to debug it. To do this, we now can simulate time in Bloc, which is really cool: > https://twitter.com/feenkcom/status/989797367523233797 > https://twitter.com/feenkcom/status/988753142299938817 > (as a side note, the bug we fought with was the last > > - Pannable element is a combination of a scrollable element with a scalable element, and it offers the possibility either to zoom in/out + scroll, or to fit screen and resize when the parent resizes. > > - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support): > https://twitter.com/feenkcom/status/976580153802358786 > https://twitter.com/feenkcom/status/976578060429484032 > > - Better curve support: > https://twitter.com/feenkcom/status/990967109193781249 > https://twitter.com/feenkcom/status/990971530615107584 > > - Better debugging support for understanding bounds: > https://twitter.com/feenkcom/status/989138457288167424 > > ---- > Brick > ---- > > - We now have simple list and columned list widgets. The list is both fast and scalable and supports rows of variable heights: > https://twitter.com/feenkcom/status/984744251920658432 > https://twitter.com/feenkcom/status/984143821192744961 > > - Basic tab widget: > https://twitter.com/feenkcom/status/974420432240685062 > > - Looks: a mechanism for specifying element-specific composition and interaction. > > ---- > GT > ---- > > - Documenter saw some major improvements. Just a reminder, Documenter is the tool that enables live programming and previews directly within Pillar documents. > We now have a capability similar to notebooks like Jupyter: > https://twitter.com/feenkcom/status/996310432225820672 > We use it extensively to document our code. For example, here is a tutorial about playing with looks in Bloc: > https://twitter.com/feenkcom/status/973899862482866176 > And we can also express whole tutorials based on Epicea: > https://twitter.com/feenkcom/status/999975333972541440 > > - Diagrammer. We now have better editing support for detailed things such as arrow head: > https://twitter.com/feenkcom/status/976341449267531776 > While Diagrammer is apparently a tool for diagrams, it has a rather generic design that can be utilized for all sorts of use cases. For example, one side effect is that now all elements can be visually edited: > https://twitter.com/feenkcom/status/982656456968241152 > > - Mondrian: Using the new pannable element, we can now zoom in/out and scroll, and we can also set element to fit screen. We can also drag elements around. > > - Inspector: we now have an initial support for multiple views associated with an object. The support is similar to the one from the current inspector. > > > Have fun, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > >

May 25, 2018

Re: [Pharo-users] Macros?

by ClÃ©ment Bera

What about a preprocessor like the Java preprocessors ? The Truffle project relies heavily on that for high performance Java and it's quite nice. It's difficult to do that in Smalltalk right now. I think if you want to do what are asking for you just need to write a bytecode compiler extension. I did something similar in the past to have precomputed constants through AST manipulation at compilation time. You can find it here with examples: http://smalltalkhub.com/#!/~ClementBera/NeoCompiler. Once the code is loaded you need to recompile the examples (NeoCompilerExample withAllSubclassesDo: #compileAll.). With it you can write code such as: [ Smalltalk vm class ] Cvalue And depending if the compiler allowsPrecompilation or not, the bytecode compiler generates: Smalltalk vm class Or just a push literal with the precomputed value (the class VirtualMachine ). In the end I decided not to use this, but you can use it and extend it to support more than just constants (any AST manipulation is possible). Just checked it works in Pharo 6. On Fri, May 25, 2018 at 4:26 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Debiller 777 <ozovozovozo202(a)gmail.com> > wrote: > > Well, I've already asked about adding new literals to pharo or > Smalltalk in > > general, however this time I have a better idea: > > macros. Can they be added? Because if I understand correctly they may be > > the only way to do that. > > Why do you think they would be a good idea? We have powerful > meta-programming facilities that are well understood and somewhat supported > by tooling. How do we get value out of macros? > > Stephan > > > > -- ClÃ©ment BÃ©ra https://clementbera.github.io/ https://clementbera.wordpress.com/

May 25, 2018

Re: [Pharo-users] Macros?

by Ben Coman

On 25 May 2018 at 21:22, Debiller 777 <ozovozovozo202(a)gmail.com> wrote: > Well, I've already asked about adding new literals to pharo or Smalltalk > in general, however this time I have a better idea: > macros. Can they be added? Because if I understand correctly they may be > the only way to do that. > Can you provide an example how how you would use a macro? cheers -ben

May 25, 2018

Re: [Pharo-users] Macros?

by Stephan Eggermont

Debiller 777 <ozovozovozo202(a)gmail.com> wrote: > Well, I've already asked about adding new literals to pharo or Smalltalk in > general, however this time I have a better idea: > macros. Can they be added? Because if I understand correctly they may be > the only way to do that. Why do you think they would be a good idea? We have powerful meta-programming facilities that are well understood and somewhat supported by tooling. How do we get value out of macros? Stephan

May 25, 2018

Re: [Pharo-users] BlueInk Pretty Printer Array Formatting

by Denis Kudriashov

Hi. I think it should be default behaviour. So open issue, please. â

May 25, 2018

Macros?

by Debiller 777

Well, I've already asked about adding new literals to pharo or Smalltalk in general, however this time I have a better idea: macros. Can they be added? Because if I understand correctly they may be the only way to do that.

May 25, 2018

Re: [Pharo-users] [Pharo-dev] feenk log

by Denis Kudriashov

Hi Tudor. Very impressive progress. I have one question about scrolling support. How it works or is it works with elements which are based on infinite layout like mentioned grid widget? Does grid implemented with PannableElement too? 2018-05-25 14:30 GMT+03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We were a bit silent the last couple of months. Quite a bit happened in > the meantime, so here is a summary (for more fine grained announcements, > you can follow us on Twitter): > > ---- > Bloc > ---- > > - Scrolling. We finally have a good scrolling support: > https://twitter.com/feenkcom/status/991690465224331264 > This might sound like a trivial feature, but it turns out it is not. We > had a bug that forced us to rethink the support quite deeply in order to be > able to debug it. To do this, we now can simulate time in Bloc, which is > really cool: > https://twitter.com/feenkcom/status/989797367523233797 > https://twitter.com/feenkcom/status/988753142299938817 > (as a side note, the bug we fought with was the last > > - Pannable element is a combination of a scrollable element with a > scalable element, and it offers the possibility either to zoom in/out + > scroll, or to fit screen and resize when the parent resizes. > > - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support): > https://twitter.com/feenkcom/status/976580153802358786 > https://twitter.com/feenkcom/status/976578060429484032 > > - Better curve support: > https://twitter.com/feenkcom/status/990967109193781249 > https://twitter.com/feenkcom/status/990971530615107584 > > - Better debugging support for understanding bounds: > https://twitter.com/feenkcom/status/989138457288167424 > > ---- > Brick > ---- > > - We now have simple list and columned list widgets. The list is both fast > and scalable and supports rows of variable heights: > https://twitter.com/feenkcom/status/984744251920658432 > https://twitter.com/feenkcom/status/984143821192744961 > > - Basic tab widget: > https://twitter.com/feenkcom/status/974420432240685062 > > - Looks: a mechanism for specifying element-specific composition and > interaction. > > ---- > GT > ---- > > - Documenter saw some major improvements. Just a reminder, Documenter is > the tool that enables live programming and previews directly within Pillar > documents. > We now have a capability similar to notebooks like Jupyter: > https://twitter.com/feenkcom/status/996310432225820672 > We use it extensively to document our code. For example, here is a > tutorial about playing with looks in Bloc: > https://twitter.com/feenkcom/status/973899862482866176 > And we can also express whole tutorials based on Epicea: > https://twitter.com/feenkcom/status/999975333972541440 > > - Diagrammer. We now have better editing support for detailed things such > as arrow head: > https://twitter.com/feenkcom/status/976341449267531776 > While Diagrammer is apparently a tool for diagrams, it has a rather > generic design that can be utilized for all sorts of use cases. For > example, one side effect is that now all elements can be visually edited: > https://twitter.com/feenkcom/status/982656456968241152 > > - Mondrian: Using the new pannable element, we can now zoom in/out and > scroll, and we can also set element to fit screen. We can also drag > elements around. > > - Inspector: we now have an initial support for multiple views associated > with an object. The support is similar to the one from the current > inspector. > > > Have fun, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > >

May 25, 2018