- Pharo-users - lists.pharo.org

Re: [Pharo-users] another Metacello question

by Dale Henrichs

Werener, Here's an example of the use of #import:provides: from my tests that might be in the area you are interested in: spec for: #'common' do: [ spec description: self name , '>>configuration092Issue63:'. spec baseline: 'External' with: [ spec repository: 'github://dalehenrich/external:' , MetacelloScriptingResource externalCustomSHA , '/repository' ]; package: 'GoferBar' with: [ spec file: 'GoferBar-lr.1'; requires: 'External-Core'; repository: 'dictionary://Metacello_Gofer_Test_Repository' ]; package: 'GoferFoo' with: [ spec file: 'GoferFoo-lr.2'; requires: 'External-Tests'; repository: 'dictionary://Metacello_Gofer_Test_Repository' ]; import: 'External' provides: #('External-Core' 'External-Tests') ] the feature was create for use with baseline project refs and my test cases all involve baselines, but I don't think that the feature is necessarily restricted to use with baseline projects ... BTW, the #import:provides: was created so that you could import specific packages/groups from more than one baseline and to also avoid importing group names from a baseline that may already exist in the project ... Dale On 2/16/16 10:04 AM, Werner Kassens wrote: > Hi Dale, > since you are reading this forum, may i ask you another qestion here > (btw i asked for access to the metacello forum, i dont know, a year > ago or so but didnt get it)? assumed i have a project (with a config) > in a baseline and several packages in that baseline with dependencies > on specific packages of this project. with that #import: method i > could model this dependencies of course, but i guess #import: is only > for git-baselines, or? if this is correct, is there a possibility to > model these dependencies without making a special project for each of > these? or simpler: project consists of packA & packB, my baseline > consists of project (only via its config) and packC & packD, packC > depends on packB, and packD depends on packA. now i want to load eg > packD via my baseline and this should of course load also packA but > not packB. (and no git involved.) > werner >

Feb. 16, 2016

Re: [Pharo-users] another Metacello question

by Dale Henrichs

Sorry about that Werner ... I had been getting my mail forwarded from the Metacello Group to my work email and apparently a year ago, the mail (silently) stopped being forwarded, so I was none the wiser until you mentioned it just now ... and I've approved your membership request along with several others that had queued up ... It would be easier for me to understand what you are proposing with an actual example of spec - the way that you'd like to see it... Also I don't quite understand what you mean by "no git involved" are you using a filetree:// repo or an mcz repository or what ... Metacello knows about github:// repos but as far as Metacello is concerned a "git repo" is just a filetree repo ... Dale On 2/16/16 10:04 AM, Werner Kassens wrote: > Hi Dale, > since you are reading this forum, may i ask you another qestion here > (btw i asked for access to the metacello forum, i dont know, a year > ago or so but didnt get it)? assumed i have a project (with a config) > in a baseline and several packages in that baseline with dependencies > on specific packages of this project. with that #import: method i > could model this dependencies of course, but i guess #import: is only > for git-baselines, or? if this is correct, is there a possibility to > model these dependencies without making a special project for each of > these? or simpler: project consists of packA & packB, my baseline > consists of project (only via its config) and packC & packD, packC > depends on packB, and packD depends on packA. now i want to load eg > packD via my baseline and this should of course load also packA but > not packB. (and no git involved.) > werner >

Feb. 16, 2016

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

by stepharo

Le 15/2/16 11:26, John Pfersich a Ã©crit : > +1 - I've been doing TDD commercially since 2003 and as far as I can tell it's a great way to squash bugs. I'd be willing to write tests. you see if you write tests for Pharo we will welcome them :) > > Sent from my iPad > >> On Feb 15, 2016, at 01:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 15 Feb 2016, at 10:27, stepharo <stepharo(a)free.fr> wrote: >>> >>> Sean I agree that TDD would really make sure that we can script such object. >>> I do not know how to motivate people to do so. >>> In bloc I started to write tests and I immediately found bugs. >>> So it was positive and may be we should have a group of people writing >>> tests. >>> Now I have to finish the mooc and I was waiting that bloc stabilise again. >>> Because I spent time writing comments and they are probably wrong now especially since >>> writing comments on thing you do not master is a PAIN. >>> >>> Stef >> The first comments (class/method), explaining the design, API and implementation, should always be written by the original authors. It helps them as well, because trying to explain something in words help to validate the design. >> >> Only in the next phase should overview/introduction/teaching/book documentation be written by others who might be better explaining things. >> >> Documentation is absolutely necessary, especially for published code. >> >> Maybe someone should run the 'missing comments' statistics again over the current 50 image ... >> >> >

Feb. 16, 2016

Re: [Pharo-users] another Metacello question

by Werner Kassens

Hi Dale, since you are reading this forum, may i ask you another qestion here (btw i asked for access to the metacello forum, i dont know, a year ago or so but didnt get it)? assumed i have a project (with a config) in a baseline and several packages in that baseline with dependencies on specific packages of this project. with that #import: method i could model this dependencies of course, but i guess #import: is only for git-baselines, or? if this is correct, is there a possibility to model these dependencies without making a special project for each of these? or simpler: project consists of packA & packB, my baseline consists of project (only via its config) and packC & packD, packC depends on packB, and packD depends on packA. now i want to load eg packD via my baseline and this should of course load also packA but not packB. (and no git involved.) werner

Feb. 16, 2016

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