Re: [Pharo-project] another kid born: NBExternalEnumerationType
>> I do not completely agree with you on this one (but you already now it). The >> thing is that if we use integers then the user will have to constantly ask >> which enum value should I pass here... > > The idea is to not expose enum values to user at all. > Sometimes it easily doable, sometimes not.. it depends , of course.. > But ideally, there should be only messages. > Just to elaborate a bit, here the real example AthensCairoPaintMode cairo has a function void cairo_set_operator (AthensCairoCanvas canvas, cairo_operator_t aCairoOperatorT) ) to set a composition operator (porter-duff one). The cairo_operator_t is indeed enum there. So, if i would use enums, users would need to tell: canvas setPaintMode: enumValue instead, the syntax to say that is following: canvas paintMode enumValueName in that way i deal with two problems: - users don't have to use shared pools in their code, more than that, it is impossible to pass some invalid value to the function. - since Athens can use multiple backends, using backend-specific enumeration values would immediately render application tightly coupled with specific backend. To avoid that, i would be needing to define own backend-neutral enumeration and then map it to backend-specific one.. This is stinks a lot to my taste.. Instead, a backend-specific AthensPaintMode subclass simply implements own method per each enumValueName for example: overlay ^ self setOperator: CAIRO_OPERATOR_OVERLAY -- Best regards, Igor Stasenko.
Re: [Pharo-project] Fwd: Lua scripting with nativeboost?
I was ready to disagree , but you do make a valid point. Also going down the pharo route you dont offer games only a better language but also a development enviroment and that is a double win. I am suprised that pharo is not used heavily for games. And no I dont believe sandbox is the reason. Afterall python is very popular with games too and has no sandbox. From: Esteban Lorenzano To: Pharo-project@lists.gforge.inria.fr Sent: Thursday, 13 December 2012, 1:45 Subject: Re: [Pharo-project] Fwd: Lua scripting with nativeboost? On Dec 12, 2012, at 7:27 PM, Marten Feldtmann wrote: > On 12.12.2012 17:18, Esteban Lorenzano wrote: > >> IMO, that's non-sense. > > Well, that is a matter of view. no, it is not. Is a matter of making a technical choice or a marketing one. You know than while a lot before any scripting language were used in gaming the "common sense" and "marketing choice" was not using anyone because "it was too slow"? if we follow what marketing says, you should do your game in C++ (or even better, plain C) and provide hooks to lua/python/whatever... technically, you lose power by choosing lua (or anything) instead pharo in an application made in pharo. people choice depends much more on the success of the game/app than the platform to make it/create extensions. I can say it not because I have the theoretical tools, I say it because I can see my nephew (9 years old) creating plugins for one game he plays, then just jump to another game and make plugins with another complete different language... what has "the marketing" to do with that? he likes his games, and he like extend them... all the other is "collateral". > I've done this also with Lua and VASmalltalk and I did this not because of > other Smalltalkers in mind using my software, but perhaps of potential end > users willing to enhance the application in a more known language. potencial users who does not know about programming will feel a lot more comfortable smalltalk than ant algol-based language. > Because of this I also tried to use Rexx as an extension language, which is > in my view even more suitable to be used as an embedded language - but the > market decided to use Lua and not Rexx. no idea about REXX... but I repeat: if the game is successful, no one cares the plugin language (and lua is not the unique scripting language for gaming around you know that) Esteban > > Marten >
[Pharo-project] I love to see the commit log on OPAL
continue this is cool :)
Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger
On Dec 12, 2012, at 11:28 PM, adrians wrote: > > Well, it just seems that I'm whining here instead of contributing, but if > the debugger is indeed a very (if not the most) useful tool which is used in > pretty much every bit of fix-up work, fixing it if it is broken would have > to come before all else, no? Otherwise, any work that needs to be done until > it is looked at is just compounded. > > Maybe it would make sense to correct (in the current code) to a small degree > just one of the things that is currently broken. No frills, but just getting > a more accurate indication of where the PC is - at least have it on the > correct line of code if it can't be pinpointed more accurately without too > much hassle. I'm curious what derails the location highlighting as half of > the time it is close, if not correct. Is it blocks that give it a hard time? > It wouldn't be too bad if other things were going to take a while if you > could at least keep track of where you were. > > If the idea is to wait until a whole big refactoring can be done on this, I > fear a fully debugger might be another year away. Your analysis is right. No this is not the idea. We never waited for big bang. But frankly I invite to come in our team to see us fully busy. Because we are doing far more than Pharo. Stef > > -- Adrian > > > > -- > View this message in context: > http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4658666p4659105.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] Zinc-Resource-Meta-[Core|Tests]
Thanks Sven We will integrated that in 2.0 Stef On Dec 12, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > Just a quick note: the first version of Zinc-Resource-Meta-[Core|Tests] > containing ZnUrl and ZnMimeType independent of / separate from / as a > dependency for Zinc-HTTP is now available. > > ConfigurationOfZincHTTPComponents version 2.0 reflects this change (#stable > for Pharo 2.x). > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >
Re: [Pharo-project] NativeBoost and Pharo Kernel
> Igor >> >> metacello can handle this situation and there is a doc. >> We can give a try together. but this is not like we do not have the tool at >> hand. >> > yes, i am not saying that it cannot handle.. i just too lazy to spend > time reading doc to figure how to do it :) well and others would be not stupid to do it… Strange logic to me.
Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger
Now adrian I imagine that you saw that people worked on this bug and this is a rather complex one. So I would suggest to you to avoid to draw conclusions too fast. Stef On Dec 12, 2012, at 11:28 PM, adrians wrote: > > Well, it just seems that I'm whining here instead of contributing, but if > the debugger is indeed a very (if not the most) useful tool which is used in > pretty much every bit of fix-up work, fixing it if it is broken would have > to come before all else, no? Otherwise, any work that needs to be done until > it is looked at is just compounded. > > Maybe it would make sense to correct (in the current code) to a small degree > just one of the things that is currently broken. No frills, but just getting > a more accurate indication of where the PC is - at least have it on the > correct line of code if it can't be pinpointed more accurately without too > much hassle. I'm curious what derails the location highlighting as half of > the time it is close, if not correct. Is it blocks that give it a hard time? > It wouldn't be too bad if other things were going to take a while if you > could at least keep track of where you were. > > If the idea is to wait until a whole big refactoring can be done on this, I > fear a fully debugger might be another year away. > > -- Adrian > > > > -- > View this message in context: > http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4658666p4659105.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] Zinc-Resource-Meta-[Core|Tests]
please add an "update zinc" ticket :) On Dec 13, 2012, at 10:24 AM, Stéphane Ducasse wrote: > Thanks Sven > > We will integrated that in 2.0 > > Stef > > On Dec 12, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > >> Just a quick note: the first version of Zinc-Resource-Meta-[Core|Tests] >> containing ZnUrl and ZnMimeType independent of / separate from / as a >> dependency for Zinc-HTTP is now available. >> >> ConfigurationOfZincHTTPComponents version 2.0 reflects this change (#stable >> for Pharo 2.x). >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > >
Re: [Pharo-project] Zinc-Resource-Meta-[Core|Tests]
On 13 Dec 2012, at 10:29, Esteban Lorenzano wrote: > please add an "update zinc" ticket :) Yes, but I was still waiting a bit, more internal Zn reorganizations are on the way, then we'll need to resync. So unless there is an immediate need, I would prefer to wait a bit. > On Dec 13, 2012, at 10:24 AM, Stéphane Ducasse > wrote: > >> Thanks Sven >> >> We will integrated that in 2.0 >> >> Stef >> >> On Dec 12, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: >> >>> Just a quick note: the first version of Zinc-Resource-Meta-[Core|Tests] >>> containing ZnUrl and ZnMimeType independent of / separate from / as a >>> dependency for Zinc-HTTP is now available. >>> >>> ConfigurationOfZincHTTPComponents version 2.0 reflects this change (#stable >>> for Pharo 2.x). >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >> >
Re: [Pharo-project] Zinc-Resource-Meta-[Core|Tests]
no problem, when you decide is ready :) On Dec 13, 2012, at 10:36 AM, Sven Van Caekenberghe wrote: > > On 13 Dec 2012, at 10:29, Esteban Lorenzano wrote: > >> please add an "update zinc" ticket :) > > Yes, but I was still waiting a bit, more internal Zn reorganizations are on > the way, then we'll need to resync. > So unless there is an immediate need, I would prefer to wait a bit. > >> On Dec 13, 2012, at 10:24 AM, Stéphane Ducasse >> wrote: >> >>> Thanks Sven >>> >>> We will integrated that in 2.0 >>> >>> Stef >>> >>> On Dec 12, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: >>> Just a quick note: the first version of Zinc-Resource-Meta-[Core|Tests] containing ZnUrl and ZnMimeType independent of / separate from / as a dependency for Zinc-HTTP is now available. ConfigurationOfZincHTTPComponents version 2.0 reflects this change (#stable for Pharo 2.x). -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill >>> >> > >
Re: [Pharo-project] Fwd: Lua scripting with nativeboost ?
Τhe success of Java shows that marketing is all you need to make something popular. Its funny because after web development (html/js/php) , Java is the most hated thing out there. Both are extremely popular :D Even if python has not been embrassed by google and used in behemoth projects like Youtube, I dont think that it would be as remotely as close to being popular as it is today. From: Igor Stasenko To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis Sent: Thursday, 13 December 2012, 10:58 Subject: Re: [Pharo-project] Fwd: Lua scripting with nativeboost? On 13 December 2012 09:54, dimitris chloupis wrote: > > I was ready to disagree , but you do make a valid point. > > Also going down the pharo route you dont offer games only a better language > but also a development enviroment and that is a double win. I am suprised > that pharo is not used heavily for games. > > And no I dont believe sandbox is the reason. Afterall python is very popular > with games too and has no sandbox. indeed, its all about marketing and having 'killer app', and then you wont notice how eagerly new people will jump into bandwagon. -- Best regards, Igor Stasenko.
Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger
On 13 December 2012 10:30, Stéphane Ducasse wrote: > Now adrian I imagine that you saw that people worked on this bug and this is > a rather complex one. > So I would suggest to you to avoid to draw conclusions too fast. > yes, if i remember, we tried to approach it at least once.. but unfortunately it requires a lot deeper knowledge about bytecode and (de)optimizations to fix highlight. > Stef > > On Dec 12, 2012, at 11:28 PM, adrians wrote: > >> >> Well, it just seems that I'm whining here instead of contributing, but if >> the debugger is indeed a very (if not the most) useful tool which is used in >> pretty much every bit of fix-up work, fixing it if it is broken would have >> to come before all else, no? Otherwise, any work that needs to be done until >> it is looked at is just compounded. >> >> Maybe it would make sense to correct (in the current code) to a small degree >> just one of the things that is currently broken. No frills, but just getting >> a more accurate indication of where the PC is - at least have it on the >> correct line of code if it can't be pinpointed more accurately without too >> much hassle. I'm curious what derails the location highlighting as half of >> the time it is close, if not correct. Is it blocks that give it a hard time? >> It wouldn't be too bad if other things were going to take a while if you >> could at least keep track of where you were. >> >> If the idea is to wait until a whole big refactoring can be done on this, I >> fear a fully debugger might be another year away. >> >> -- Adrian >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4658666p4659105.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-project] How to load Phoseydon and Neptuno?
Hi! which Pharo version are you using? I was able to download Phoseydon in Pharo 1.4 by doing Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfDBXTools'; load. (((Smalltalk at: #ConfigurationOfDBXTools) perform: #project) perform: #version: with: #stable) load: 'Phoseydon' as it is in the webpage... What problem did you find? BTW, I would move this thread to dbxt...@googlegroups.com or the pharo-users mailing lists. Cheers, Guille On Wed, Dec 12, 2012 at 11:07 PM, Stan Shepherd wrote: > Hi all, is there a working snippet to load these two? I've tried > combinations > from previous threads without success so far. > Thanks,...Stan > > > > -- > View this message in context: > http://forum.world.st/How-to-load-Phoseydon-and-Neptuno-tp4659102.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >
[Pharo-project] pharo-2.0-tests » win - Build # 501 - Still Failing!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./label_exp=win/501/Project:label_exp=winDate of build:Thu, 13 Dec 2012 11:46:31 +0100Build duration:40 secCHANGESNo ChangesCONSOLE OUTPUTStarted by upstream project "pharo-2.0-tests" build number 501originally caused by: Started by upstream project "Pharo-2.0" build number 506originally caused by: Started due to content change in http://pharo.gforge.inria.fr/updates/pharo2.0/updates20.list[URLTrigger] A change within the response URL invocation (log)Building remotely on pharo-win7-64 in workspace C:\jenkins\workspace\pharo-2.0-tests\label_exp\winDeleting project workspace... doneNo emails were triggered.[win] $ sh -xe C:\Windows\TEMP\hudson6727937313690435019.sh+ echo 'mkdir -p C:\jenkins\workspace\pharo-2.0-tests\label_exp\win'mkdir -p C:\jenkins\workspace\pharo-2.0-tests\label_exp\winCopied 317 artifacts from "Scripts-download" build number 1724Unable to find project for artifact copy: Cog-VM/Architecture=$Architecture,OS=winThis may be due to incorrect project name or permission settings; see help for project name in job configuration.Build step 'Copy artifacts from another project' marked build as failureArchiving artifactsRecording test resultsDescription set: Email was triggered for: FailureSending email for trigger: Failure
Re: [Pharo-project] Zinc-Resource-Meta-[Core|Tests]
I added the entry. stef
Re: [Pharo-project] who is "dfgs"?
haha, so these are commits from the pre-full-name aera. Anyway, dfgs was a student in bern ;), but since I put the code in the system I should be the owner ;). VTerm*Driver abstract over the terminal, and yes they are crucial for any decent terminal support. - provide colors for terminal - provide cursor navigation - provide terminal capability access due to lack of NativeBoost in the main image, so far I could not use tcap, but that will change. So far I did not port the input handler (but there is a fully fledged smalltalk-based readline implementation ready). Once that is in the image there should be no more undefined calls. And using #perform: is a very bad habit in my opinion. It breaks all tools, since you make everything implicit (and quite slow as well).. On 2012-12-11, at 09:05, Esteban Lorenzano wrote: > ... and please, please, please, use real names, not initials when committing > packages! > > Esteban > > On Dec 11, 2012, at 11:33 AM, Pavel Krivanek wrote: > >> Hi, >> >> I would like to ask who has the initials "dfgs". And I have a question for >> him/her. The VTermInputDriver initialization methods generate a lot of >> unimplemented calls because they expect a handler object with protocol that >> is not defined in the image. Do we need the VTerm classes at all? Can you >> provide an abstract handler class? Or what about to switch this calls to >> perform:/perform:with: form. >> >> Cheers, >> -- Pavel >> >> > >
Re: [Pharo-project] About (backwards) Compatibility
> > I hate to keep repeating myself, but the Pharo manifesto is very clear, and > makes these types of arguments moot: > - Better for the better > - Beauty to learn from > - Not backward compatible > - Clean, lean and fast And we pay attention about change we will not change filesystem every release or announcement. Stef
Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger
On Thu, Dec 13, 2012 at 10:40 AM, Igor Stasenko wrote: > On 13 December 2012 10:30, Stéphane Ducasse wrote: >> Now adrian I imagine that you saw that people worked on this bug and this is >> a rather complex one. >> So I would suggest to you to avoid to draw conclusions too fast. >> > yes, if i remember, we tried to approach it at least once.. > but unfortunately it requires a lot deeper knowledge about bytecode > and (de)optimizations to fix highlight. > I looked at it a bit on the train... With the new infrastructure, we create an intermediate representation which is (nearly) a 1:1 mapping to bytecode (some are mapped to multiple bytecode, multiple IR nodes can result in just one BC), but mostly: 1:1 mapping. The nice thing is that the IRnode records the offset of the bytecode when bytecode is emitted. And the IR knows the AST Node it was created from. And the AST node knows everything (down to the Tokens and the offset in the source text). after adding #instructionForPC: to IRMethod (which just searches for the node), the following code just works: | method astNode| method := Integer>>#+. astNode := (method parseTree ir instructionForPC: 58) sourceNode. method sourceCode copyFrom: astNode debugHighlightStart to: astNode debugHighlightStop returns 'ifTrue: [^ (self digitAdd: aNumber) normalize] ifFalse: [^ self digitSubtract: aNumber]' This needs to be tested and enhanced a bit (e.g. for the case that one IR created multiple bytecodes, e.g. block pre-amble and postscript...). But it should not be that hard to do, I think. The good thing is that it does not rely on some table that is created somewhere, but instead you have the data (IR and AST) directly there to look at. Tweaking special cases should be quite easy with that. Marcus -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de
[Pharo-project] How to load Phoseydon and Neptuno?
Are there plans for SqueakDBX regarding porting it to Pharo 2.0 or moving it from FFI to NativeBoost?
Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger
Indeed we spent some time in Edinburgh looking at it :-) that was too long ago :-( The problem i see with the original debugger inherited from Squeak, in the Pharo context, is that it is very sensitive to a lot of the core code in the image. What this means is that the accelerated changes in Pharo code base had unintended side effects on original debugger machinery as it diverged from its ancestry. It goes all the way back to pushing Eliot's closure implementation in 1.0 which we were desperate and excited for. Since we relied on taking core compiler/closure/debugger code from Squeak it became more and more important to track the difference between squeak and Pharo. Anyone who has tried looking at the diffs will know how hard that is. I forget which class it was but we found this obscure bug in one of the collection classes IIRC that threw one tiny but annoying aspect of debugger highlighting off. I only found that by single stepping both images through known code snippets with this debugger 'oscilloscope' I had hacked up for the purpose. What that experience showed was it was really involved how the instruction machinery hangs together. As squeak trunk is where most fixes get pushed in this area it requires huge resources and diligence to track every change to see if Pharo needs it. For ages Stef would post every interesting looking trunk change to the pharo bug tracker but there were not many folks looking at them all. And also it is not nice work. We didn't have the tools or modularity to cherry pick changes in this area. So the new debugger model in Glamorous showed an interesting direction to go in and this comment from Marcus is also interesting on seemingly building a new debugger architecture which we have discussed before. I was trying to do was to figure out a way you could regression test the debugger by recording and replaying examples of it's operation and checking each release it hadn't been broken unexpectedly. I think there is still mileage in that area if it has not been done already. Also, historically, I am not convinced it was ever properly working in the sapphire build or even in 3.9. The bugs and effects were so subtle that you just got used to working around them. I.e. I have 20 mins to do some coding do I add a bit more to my cool seaside app or do I struggle with fixing the debugger? Last I looked at squeak trunk it was looking pretty good. But the code base is hard to track. What I was last thinking about in this area was trying to live 'trace' in some way all the code required by the debugger into a filed out and renamed set of classes like :SqDebugger SqArray SqCompiler SqInstructionStream and so on and then load them into Pharo. The idea being you would have an identical implementation that you would use to operate on all the Pharo code but entirely independent from it and maintained in squeak trunk. It is an unrealistic idea but the example i was thinking about from the electronic world is using one oscilloscope to test or observe the internals of another. You could do that image to image over the network of course but I am not sure if you just vary the complexity in a different direction. Anyway just my 2p, I care a lot I about the tooling and look forward to seeing what comes out! Cheers, Mike (a bit absent, but still enjoying the progress) On 13 Dec 2012, at 09:40, Igor Stasenko wrote: > On 13 December 2012 10:30, Stéphane Ducasse wrote: >> Now adrian I imagine that you saw that people worked on this bug and this is >> a rather complex one. >> So I would suggest to you to avoid to draw conclusions too fast. >> > yes, if i remember, we tried to approach it at least once.. > but unfortunately it requires a lot deeper knowledge about bytecode > and (de)optimizations to fix highlight. > >> Stef >> >> On Dec 12, 2012, at 11:28 PM, adrians wrote: >> >>> >>> Well, it just seems that I'm whining here instead of contributing, but if >>> the debugger is indeed a very (if not the most) useful tool which is used in >>> pretty much every bit of fix-up work, fixing it if it is broken would have >>> to come before all else, no? Otherwise, any work that needs to be done until >>> it is looked at is just compounded. >>> >>> Maybe it would make sense to correct (in the current code) to a small degree >>> just one of the things that is currently broken. No frills, but just getting >>> a more accurate indication of where the PC is - at least have it on the >>> correct line of code if it can't be pinpointed more accurately without too >>> much hassle. I'm curious what derails the location highlighting as half of >>> the time it is close, if not correct. Is it blocks that give it a hard time? >>> It wouldn't be too bad if other things were going to take a while if you >>> could at least keep track of where you were. >>> >>> If the idea is to wait until a whole big refactoring can be done on this, I >>> fear a fully debugger mi
Re: [Pharo-project] How to load Phoseydon and Neptuno?
On Thu, Dec 13, 2012 at 6:40 PM, Torsten Bergmann wrote: > Are there plans for SqueakDBX regarding porting it to Pharo 2.0 > or moving it from FFI to NativeBoost? > > It would be a nice idea. And not hard to do since the functions of OpenDBX are quite easy to wrap: easy types and no need of callbacks. Only one external structure. Unfortunately, right now my plate is full. If someone wants to take a look, I can provide more details on how that should be done. Cheers, -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] [squeak-dev] FileSystem (was: About (backwards) Compatibility)
>> Yes, of course those capabilities could be added simply with factoring >> work and little disruption to the API. That's the promise object >> technology, encapsulation. > > The main problem with FileDirectory that there's no API. > I can hardly call a single class as API... > as to me, it is clear that file system domain is a bit more complex > and in order to reflect it properly in a language you will need more > that a single role (FileDirectory). FileDirectory is actually made up of 10 classes providing a rich but utilitarian API for traversal, navigation, stream creation, copying and renaming, filename parsing utilities. Platform-specific implementations all share the same API, including one for remote FTP access. For you to say "no API" is silly. > So, i really doubt that you end up with 'little disruption to API'. It > will be substantial. > > To me, design comes first. ALWAYS. > All of the rest is secondary. Design should be a means to some end, not an end in itself. You can design for 20 years but if real-world results are never harvested then it was only ever just playing around with a cool toy. My goal is to get as far along my software journey as my limited lifespan will allow.. > FileSystem establishing a clear > separation between conceptual model > ... snip ... > won't require serious changes and will serve you much much longer > without need to change anything in userland code. (Take a Collection > protocols for example). .. and so when I become faced with having to make "serious changes" in my "userland code," (e.g., a complex ODBMS system) just to hold position along my journey; naturally I'm resistant. You can try to justify it with design theory but, at the end of the day, the two frameworks do basically the same thing, converting to it is mostly pure cost. > Also, once you have such set of rules, it is much easier for people to > maintain implementation code, > as well as adding extra functionality if needed. > > Clearly, VM interfaces (such as primitives) should be not exposed to > ... Igor, a very good explanation for our individual views here is that your journey is building a great new Smalltalk, mine is something else. Cheers, Chris
Re: [Pharo-project] [squeak-dev] FileSystem (was: About (backwards) Compatibility)
On 13/12/12 10:24 PM, Chris Muller wrote: Igor, a very good explanation for our individual views here is that your journey is building a great new Smalltalk, mine is something else. I don't see that as a good explanation. I see different paths to similar goals. The Igor/Pharo path is to first improve the Smalltalk, and from that platform, scale even greater heights than could have been imagined from the "random walk" along "safe" path.
Re: [Pharo-project] [squeak-dev] FileSystem (was: About (backwards) Compatibility)
On 14 December 2012 05:13, Yanni Chiu wrote: > On 13/12/12 10:24 PM, Chris Muller wrote: >> >> >> Igor, a very good explanation for our individual views here is that >> your journey is building a great new Smalltalk, mine is something >> else. > > > I don't see that as a good explanation. I see different paths to similar > goals. The Igor/Pharo path is to first improve the Smalltalk, and from that > platform, scale even greater heights than could have been imagined from the > "random walk" along "safe" path. > right. the same as Marcus says about "base camp": You can climb mountain each time from the very bottom of it, or you can prepare first, and build a base camp which will make your expedition less difficult. -- Best regards, Igor Stasenko.
Re: [Pharo-project] How to load Phoseydon and Neptuno?
What are Phoseydon and Neptuno? New kind of browsers? Alexandre On Dec 13, 2012, at 10:49 AM, Guillermo Polito wrote: > Hi! > > which Pharo version are you using? I was able to download Phoseydon in Pharo > 1.4 by doing > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfDBXTools'; > load. > > (((Smalltalk at: #ConfigurationOfDBXTools) > perform: #project) > perform: #version: with: #stable) > load: 'Phoseydon' > > as it is in the webpage... > What problem did you find? > > BTW, I would move this thread to dbxt...@googlegroups.com or the pharo-users > mailing lists. > > Cheers, > Guille > > On Wed, Dec 12, 2012 at 11:07 PM, Stan Shepherd > wrote: > Hi all, is there a working snippet to load these two? I've tried combinations > from previous threads without success so far. > Thanks,...Stan > > > > -- > View this message in context: > http://forum.world.st/How-to-load-Phoseydon-and-Neptuno-tp4659102.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
