February 2016 - Pharo-users

Re: [Pharo-users] Metacello reverse project dependency

by Dale Henrichs

Peter, Very good summary ... First off, Metacello doesn't support circular project dependencies. Secondly, there is supposed to be a "cucularity detector" in Metacello that avoids going into an infinite loop, but in retrospect, the detector has not been tested with Baselines - I have submitted a bug[1] Presumably in your second scenario all of the packages load correctly, except that the extensions methods are not loaded ... is that correct? I think you should be able to address your problem by using the #atomic load type, by adding the following method to each of your baselines: project ^ project ifNil: [ project := super project. project loadType: #'atomic'. project ]. The default #linear load type loads each package individually. The #atomic load type loads all of the accumulated definitions at one time and missing dependencies like the one you are seeing should be resolved by load time ... The accumulation of definitions crosses project boundaries. I've submitted a bug to make changing the default load type a bit easier[2] ... sometimes I wish that I made #atomic load the default, but it is hard to change defaults in midstream without causing lots of breakage... Let me know if this addresses your issue. Dale [1] https://github.com/dalehenrich/metacello-work/issues/383 [2] https://github.com/dalehenrich/metacello-work/issues/384 On 2/16/16 12:33 AM, Peter UhnÃ¡k wrote: > Unfortunately #includes: doesn't seem to matter and I still get errors. > > I tried to somehow summarize my findings with minimal code & results > here http://peteruhnak.com/metacello/ > > On Mon, Feb 15, 2016 at 11:31 PM, Werner Kassens <wkassens(a)libello.com > <mailto:wkassens@libello.com>> wrote: > > Hi Peter, > have you looked at metacellos #includes: method? > from > https://code.google.com/archive/p/metacello/wikis/APIReference.wiki : > "When 'Example-AddOn' is loaded, load 'Example-UI'" > includes: #('Example-UI' ); > werner > > On 02/13/2016 11:26 PM, Peter UhnÃ¡k wrote: > > Hi, > > I have the following situation: > > I have ProjectMain, and ProjectPlugin, now normally the Plugin > depends > on Main, however I would like to load Plugin as part of Main. > > The problem is that I can't specify to load Plugin after Main > has been > already fully loaded, if I do something like this > > BaselineOfMain>>baseline: spec > <baseline> > spec > for: #common > do: > [ spec > baseline: 'Plugin' > with: [ spec > repository: '...'; > loads: #('default' OR 'plugin') ]. > spec > package: 'Main' with: [ spec requires: #(more stuff) ]; > spec group: 'default' with: #('Main'). > specgroup: 'complete' with: #('default' 'Plugin') ] > > The BaselineOfPlugin has two groupsâ¦ "default", which loads > also "Main", > and "plugin", which doesn't. > > Now the problem is that there is no guaranteed way that Plugin > will load > after Main (in fact the should happen). If I load the plugin's > #default, > then Metacello ends up in an endless loop for some reason, and > if I load > #plugin, then it will load it before the Main which will break it > (because Plugin has dependencies on main). > > So my question is: > is it possible to reverse it somehow? > Maybe add at the end `specpostLoadDoIt: #postLoadPlugins`, and > then in > that method manually load the plugins with Metacello/Gofer? Or > is there > a better way? > > Thanks, > Peter > > >

Feb. 16, 2016

AST documentation

by kilon.alios

Is there any documentation for the Pharo AST and any ways to affect Pharo syntax ? -- View this message in context: http://forum.world.st/AST-documentation-tp4877909.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Compiling Pharo to C++

by kilon.alios

"Then I guess you can do something like Slang, which is used for the VM. Slang is a restrictive Smalltalk compiling to C. " I dont think Slang is close to what I am trying to do, last time I checked Slang out it appeared to me that Slang is trying to create as much smalltalk syntax as possible. My goal is the other way around to create C++ code by sticking as close to C++ syntax as possible but still using syntax that will make porting pharo code easier. " The slang compiler parses the code using the Smalltalk Compiler parser, then translate the Smalltalk AST to its own AST, " Yeap thats the approach I am interested into as well. Take the Smalltalk AST and translate to an AST very close to C++. I am not interested into creating an in between language. "I am not saying that slang is a nice language and that you should do something similar. Slang is horrible. " Why Slang is horrible according to you ? "But in the case of the VM is has some significant advantages over C++ and method templates." Indeed the VM is awesome but as I said my main goal is not to keep the pharo features but rather to produce very readable C++ code. So I have little problem sacrificing those features. I probably end up making my own variant of the Pharo language that can happily coexist with the existing pharo language. "Not entirely true [1].... [1] https://forums.unrealengine.com/showthread.php?3958-Scripting-Language-exte… " Still Pharo is no Lua and it cannot embed itself. What I meant was that its not actively supported. Also its not that simple because one has to expose C++ to the scripting language. I rather have something that produces C++ and I can easily integrate. Or maybe there is something I am missing here and its far easier than I assume. Even without your link embeding lua and python in existing C++ executable is not that hard. Those language offer good support for this and they are heavily used for this task. I also spoke with Esteban about embedding pharo and he told me that pharo has a long way to go before it is able to do this. So for the time being I will start playing around with the Pharo AST and see if I can start generate super simple C++ code out of it and see how hard really it is and move step by step, thank you all for the suggestions. -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp4877775p4877898.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Compiling Pharo to C++

by Ben Coman

> Unreal assumes that you either write C++ code > or using their own scripting language "Blueprint". Not entirely true [1].... [1] https://forums.unrealengine.com/showthread.php?3958-Scripting-Language-exte… On Tue, Feb 16, 2016 at 5:42 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Are you sure C++ compilation is the best way ? There are a lot of flaws: > Smalltalk needs to be restrictive or will be compiled to very slow code, you > will loose debugging features, etc. > > I would try to integrate Pharo the same way lua is integrated in engines > like Source2 from valve: you run your Unreal engine and have it call Pharo > as a scripting language to code some features. Something like [2], scrolling down to the #include ? [2] http://accu.org/index.php/journals/351 What would be the Cog equivalent of...? lua_State* L = lua_open(); and what would be a good starting point to look at this? main() and fakevm() in threadValidate.c [3] seem to lay out a basic structure. [3] https://git.io/vg7bn I see interpret() called from: * platforms/unix/vm/sqUnixMainNoDisplay.c [4] and * iOS/vm/Common/Classes/sqSqueakMainApplication.m [5] but can't see where this is implemented. [4] https://git.io/vg5fB [5] https://git.io/vg5JS I guess the new SDL derived headless mode mentioned recently would help with embedding Pharo in another program? cheers -ben > In such case, one needs to > make the VM embeddable in a C++ app, but on the vm-dev mailing list people > can help you to do so. Then you need to define some APIs based on what exist > in the interpreter proxy to easily call Pharo methods and share struct / > objects from C++. Lastly, you may consider adding a few settings in FFI. By > default the Smalltalk stack and the C stack are separated to to Smalltalk > specific stack page handling. I guess with some annotation in Pharo API code > called from C++ you could define the case where the stack could be shared or > not. > > While compiling to C++, how to you plan your compiler to manage memory ? > > > 2016-02-16 9:52 GMT+01:00 kilon.alios <kilon.alios(a)gmail.com>: >> >> So doing further research into Unreal , I have reached the conclusion that >> the best way to integrate Pharo is make a compiler that takes Pharo code >> and >> compiles it to C++. >> >> I have barely scratch such area when I was playing around with Pharo AST >> nodes. Any advice / ideas how to accomplish this ? >> >> Currently my goal is to start super simple, with compiling small pharo >> code >> fragments to C++ code and then much later on even introduce extensions to >> the pharo language to accommodate for C++ features like templates , >> pointers >> (FFI probably already cover this) , static types etc. Obviously if I can >> keep the pharo syntax intact would be the ideal option.

Feb. 16, 2016

Re: [Pharo-users] Bloc Space within a Space

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > ok, so not infeasible but we are not there today... lets do it step by > step. Okay :) Thanks for thinking through this with me. I've had an idea for years which I'm very excited about that requires this functionality, and I've been waiting for a tool powerful and flexible enough to implement it! It looks like Bloc will be that tool and I'm happy to help and wait a bit longer... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877878.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Compiling Pharo to C++

by ClÃ©ment Bera

Ok. Then I guess you can do something like Slang, which is used for the VM. Slang is a restrictive Smalltalk compiling to C. The slang compiler parses the code using the Smalltalk Compiler parser, then translate the Smalltalk AST to its own AST, do some manipulation based on pragmas available in Slang methods and inlines different things based on a closed world (you can know what method is called at each send site) / frozen state assumptions (The value of literal variable will not change). Some selectors are specifically mapped to C instructions / macros, for example #cppIf:ifTrue: maps to #IFDEF, or bitShift: maps to signed long bitShift. Comment are translated from Smalltalk to C and they are really useful. Another interesting thing is that due to inlining part of the allocation / deallocation can be avoided. You can't really use Slang directly as its implementation is tied with the VM (each time we have a slang bug in the vm code, we choose to either change the slang compiler or the slang code depending on how much work is each task). I am not saying that slang is a nice language and that you should do something similar. Slang is horrible. But in the case of the VM is has some significant advantages over C++ and method templates. 2016-02-16 11:30 GMT+01:00 kilon.alios <kilon.alios(a)gmail.com>: > "Hi Kilon, > > the way your are explaining it, it seems you are trying to build a > Smalltalk-like syntax in C++ via templates? > > It could make moving a software architecture from Smalltalk to C++ > significantly easier (and open maybe some opportunities). > > Thierry" > > Bingo ! You get it ! > > Thats what is all about about moving code from Pharo to C++ and NOT > reimplementing Pharo in C++ as some people assumed. Yes if I can go for > smalltalk-syntax that would be a fair compromise, ideally i want to keep > Pharo syntax intact and introduce C++ features like static types , pointers > etc through the use of pharo objects. > > For example I can make an object to represent a C++ int, what stops me from > taking pharo class variable make it initialise with that int object then > later on use a string instead ? > > Nothing, my compiler wont even complain, but when you turn it to C++ code > and try to compile it you will get C++ errors. > > On the subject of templates, again there wont be magical transormation of > dynamic types to C++ templates at least not in the start since C++ expect > to > be explicity about the use of a template that will carry on to my tool as > well. That means that the pharo code will have to be explicit and leave > nothing to chance like a C++ coder does. > > Essentially you coding C++ using pharo syntax or pharo like syntax > depending > on how succesful I will be with this. Also creating readable code is a must > do. > > For example I have taken a look at chicken and gambit scheme that take > scheme (lisp variant) and turn to C and then call the c compiler to make > the > machine code executable. The problem is that C code is unreeadable because > it tries to emulate dynamic types etc. My goal is so not to retain Pharo > features and dynamism but rather to produce C++ that is not only readable > but proper C++ code with comments , good names, etc. > > My thinking however is like this: > > 1) Prototype in Pharo and make sure it works well using all the features > and > tools of pharo (dynamic types, GC, live coding, live debugging etc) > 2) convert your code to my language that looks a lot like pharo but with > all > the C++ features leaving no ambiguities for the compiler > 3) use my compiler to turn a specific fragment of code to C++ > 4) go back to to (1) > 3) > > > > -- > View this message in context: > http://forum.world.st/Compiling-Pharo-to-C-tp4877775p4877838.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 16, 2016

Re: [Pharo-users] Metacello reverse project dependency

by Werner Kassens

Hi Peter, ah i see, at least i know now why i dont like git <g>. in your 2nd ex there is perhaps still a circular dependency, what happens if the baselines of bar & zar do not rely on baselineoffoo, which isnt used there anyway ? werner On 02/16/2016 11:30 AM, Peter UhnÃ¡k wrote: > Don't look at the metacello version numbersâ¦ versions are maintained by > git Â--- so I can have the same version number refering to different > code in different branches. (There's no clash because one branch will > never know about another one.)

Feb. 16, 2016

Re: [Pharo-users] Compiling Pharo to C++

by Thierry Goubier

Hi Kilon, the way your are explaining it, it seems you are trying to build a Smalltalk-like syntax in C++ via templates? It could make moving a software architecture from Smalltalk to C++ significantly easier (and open maybe some opportunities). Thierry 2016-02-16 11:00 GMT+01:00 kilon.alios <kilon.alios(a)gmail.com>: > Ok first my apology to people because I see that many have misunderstood my > motivation. > > So let me be crystal clear. > > *This IS NOT an effort to make Pharo "super cool". "Look mom Pharo compiles > to C++ magically, it runs blazzing fast, it can use C++ libraries with zero > efforts" and similar none sense.* > > Unfortunately I cannot use Pharo as a scripting language that would be > awesome but I afraid not possible. Compiling Unreal as a set of dlls is > somewhat possible but the problem is that iOS does not allow dlls, iOS > support is super crucial for me so that goes out of the window. Embeding > Pharo in Unreal is no go either since pharo does not support this. > > I am not looking into bringing Pharo features to C++. For example I dont > care about dynamic types because Unreal depends a lot on templates which > are > very dynamic, I dont care about Pharo GC because unreal has its own GC, I > dont care about Pharo reflection because Unreal also gives C++ reflection > features, I dont even care about Pharo live coding because Unreal also > allow > to hot reload on the fly when you recompile C++ code. > > WARNING !!! I am not saying that coding C++ in Unreal is better , more > dynamic or more live than Pharo. Pharo is awesome. > > So my thinking is like this, I cannot avoid C++. So since I cannot avoid it > then maybe I could try to make it more enjoyable by making it move closer > to > pharo syntax. > > That means my implementation will do a lot of nasty compromises, meaning > manual memory managment, disallow dynamic types (though later on with the > help of templates maybe I can make it more dynamic) , have to include > headers etc. So in general write C++ code using something that is close to > pharo syntax. My goal is not an ideal solution but a practical solution > something that is relative simple to make for a single developer. > > It wont be a tool you guys will be using because it will be too tied to > Unreal anyway and it will contain the nasty parts of C++. The idea will be > similar to what Cython is for python, start prototyping in pure python with > all the great features it has, then when code works as you expect start > inserting static types, manual memory management etc to turn it to C++. > > I hope now I am much more clear what I aiming for > > > > > > > > > > > > > -- > View this message in context: > http://forum.world.st/Compiling-Pharo-to-C-tp4877775p4877821.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 16, 2016

Re: [Pharo-users] Metacello reverse project dependency

by Peter UhnÃ¡k

Don't look at the metacello version numbersâ¦ versions are maintained by git Â--- so I can have the same version number refering to different code in different branches. (There's no clash because one branch will never know about another one.) The important is what is fetched from github: Fetched -> BaselineOfBar-PeterUhnak.11 --- github://peteruhnak/ci-bar: *cycle*/repository* [6ac72c0:cycle]* --- github://peteruhnak/ci-bar:*cycle* /repository Fetched -> BaselineOfBar-PeterUhnak.11 --- github://peteruhnak/ci-bar:*deps*/repository *[03d743b:deps]* --- github://peteruhnak/ci-bar:*deps*/repository On Tue, Feb 16, 2016 at 11:17 AM, Werner Kassens <wkassens(a)libello.com> wrote: > Hi Peter, > in your second example, which has a new BaselineOfZar & of bar, > BaselineOfZar-PeterUhnak.9 & BaselineOfBar-PeterUhnak.11 is fetched, which > have the same versionnumber as in the 1st example, are you sure, that the > new baselines of ex2 are loaded? > werner > > > On 02/16/2016 09:33 AM, Peter UhnÃ¡k wrote: > >> Unfortunately #includes: doesn't seem to matter and I still get errors. >> >> I tried to somehow summarize my findings with minimal code & results >> here http://peteruhnak.com/metacello/ >> >> >

Feb. 16, 2016

Re: [Pharo-users] Compiling Pharo to C++

by kilon.alios

"Hi Kilon, the way your are explaining it, it seems you are trying to build a Smalltalk-like syntax in C++ via templates? It could make moving a software architecture from Smalltalk to C++ significantly easier (and open maybe some opportunities). Thierry" Bingo ! You get it ! Thats what is all about about moving code from Pharo to C++ and NOT reimplementing Pharo in C++ as some people assumed. Yes if I can go for smalltalk-syntax that would be a fair compromise, ideally i want to keep Pharo syntax intact and introduce C++ features like static types , pointers etc through the use of pharo objects. For example I can make an object to represent a C++ int, what stops me from taking pharo class variable make it initialise with that int object then later on use a string instead ? Nothing, my compiler wont even complain, but when you turn it to C++ code and try to compile it you will get C++ errors. On the subject of templates, again there wont be magical transormation of dynamic types to C++ templates at least not in the start since C++ expect to be explicity about the use of a template that will carry on to my tool as well. That means that the pharo code will have to be explicit and leave nothing to chance like a C++ coder does. Essentially you coding C++ using pharo syntax or pharo like syntax depending on how succesful I will be with this. Also creating readable code is a must do. For example I have taken a look at chicken and gambit scheme that take scheme (lisp variant) and turn to C and then call the c compiler to make the machine code executable. The problem is that C code is unreeadable because it tries to emulate dynamic types etc. My goal is so not to retain Pharo features and dynamism but rather to produce C++ that is not only readable but proper C++ code with comments , good names, etc. My thinking however is like this: 1) Prototype in Pharo and make sure it works well using all the features and tools of pharo (dynamic types, GC, live coding, live debugging etc) 2) convert your code to my language that looks a lot like pharo but with all the C++ features leaving no ambiguities for the compiler 3) use my compiler to turn a specific fragment of code to C++ 4) go back to to (1) 3) -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp4877775p4877838.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016