Re: [Pharo-dev] on:do: for shortcuts?
excellent so how do we integrate this change? I will chnage the chapter on keymapping :) On Jun 18, 2013, at 9:57 PM, Guillermo Polito wrote: > I prefer the onKeyCombination* because of the following rationale: > > - to me a shortcut is the association between a key combination and an action > - a key combination is a combination of keys :), which is associated with an > action > > Stef, so far I changed the asShortcut => asKeyCombination, following the same > idea :). > > Guille > > > On Tue, Jun 18, 2013 at 8:25 PM, Stéphane Ducasse > wrote: > > On Jun 18, 2013, at 7:21 PM, GOUBIER Thierry wrote: > > > The problem with onkeypress, onkeydown, onkeyup is that they are low-level > > events compared to the shortcuts we are talking about. > > > > A shortcut is at least one key, but is usually a key + a modifier or a > > sequence of key + modifiers (such as the emacs ^X ^C ($x ctrl, $c ctrl). > > The Keymapping stuff sits a lot higher than the basic keypress events > > (which do exist as well) and can recognize multi-keys combinations. If you > > call that onKeyPress:do:, then you loose in the name part of the power of > > it. > > > > Hence the onKeyCombination:do: (but I prefer onShortcut:do:) > > onShortcut:do: looks good to me. > > Stef > > > > > > Thierry > > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Esteban A. > > Maringolo [emaring...@gmail.com] > > Date d'envoi : mardi 18 juin 2013 18:14 > > À : Pharo Development List > > Objet : Re: [Pharo-dev] on:do: for shortcuts? > > > > 2013/6/18 Clément Bera > > > >> On Javascript, there are : > >> > >> onkeypress > >> onkeydown > >> onkeyup > >> > >> > >> I think we should have same API than other languages, especially popular > >> ones. So 1 of these 3 would be the best for me. > >> > >> Why not onKeyPress:do: ? > > > > +1 to each of the last two statements. > > > > > > >
Re: [Pharo-dev] [update 3.0] #30207
On 19 Jun 2013, at 08:46, Marcus Denker wrote: > 30207 > - > > 10944 Enable Opal in 3.0 > https://pharo.fogbugz.com/f/cases/10944 > > Just does a > > SmalltalkImage compilerClass: OpalCompiler. > OpalCompiler recompileAll. > > Yes… we managed to run out of known bugs. So let's find some more… :-) Great work. It was impressive to see all this activity the last couple of months. It feels good that so much testing and QA was done. Thx, Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Re: [Pharo-dev] Block Printing in 3.0
On 19 Jun 2013, at 08:52, Marcus Denker wrote: > > On Jun 13, 2013, at 2:48 PM, Marcus Denker wrote: > >> >> On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris wrote: >> >>> Why do we get [...] when Opal is not active? Why can't we keep the old >>> behavior? >>> >> >> >> Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) >> We where a bit distracted last week so there was no progress on those… soon. >> > > Blocks are now pretty-printed again. > > In addition, the new bytecode->AST->source mapping is active, this should > speed > up the Debugger a bit and should fix some long standing highlighting bugs. > > (But due to the inherent complexity of the whole thing, it fire sure will > have some > problems, we will see. The good thing is that problems should be easy to > debug > due to the explicit AST/IR based mapping) > > Marcus > Yes, for end users, improving the debugger based on Opal should be the next step. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Re: [Pharo-dev] Block Printing in 3.0
On Wed, Jun 19, 2013 at 9:35 AM, Sven Van Caekenberghe wrote: > Yes, for end users, improving the debugger based on Opal should be the next > step. when do we activate the new debugger by default? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Re: [Pharo-dev] [update 3.0] #30207
On Wed, Jun 19, 2013 at 8:46 AM, Marcus Denker wrote: > Yes… we managed to run out of known bugs. So let's find some more… :-) Marcus is on fire this morning!! Keep going. It's not even 10am, so the best is still to come. 2 hours left :-). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Re: [Pharo-dev] Also "create method" in traits
On Tue, Jun 18, 2013 at 3:48 PM, Sebastian Tleye wrote: > Done :) > You can download the fix and not suffer anymore :P thank you Sebastian. It's very cool to see you in this mailing list. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Re: [Pharo-dev] A little demo of Cade
2013/6/19 Damien Cassou > On Tue, Jun 18, 2013 at 11:23 PM, Tristan Bourgois > wrote: > > I hope you like this little demo :) And I hope I could make some others > :) > > > That's really awesome work Tristan. Nevertheless, the 4th part of the > video is completely black for me. When will Cade be open-sourced :-)? > > Oh I forgot to put it in the video. Normally you have a view with more than 4000 shape displaying. May be I will put it in other demo because this demo is a bit old I made some upgrade on the framework especially about performance. When cade will be open-sourced... Hum good question... I have a lot of paperwork to do. > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >
Re: [Pharo-dev] Also "create method" in traits
:-) 2013/6/19 Damien Cassou > On Tue, Jun 18, 2013 at 3:48 PM, Sebastian Tleye wrote: > > Done :) > > You can download the fix and not suffer anymore :P > > > thank you Sebastian. It's very cool to see you in this mailing list. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >
Re: [Pharo-dev] Block Printing in 3.0
On Jun 19, 2013, at 9:35 AM, Sven Van Caekenberghe wrote: > > On 19 Jun 2013, at 08:52, Marcus Denker wrote: > >> >> On Jun 13, 2013, at 2:48 PM, Marcus Denker wrote: >> >>> >>> On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris wrote: >>> Why do we get [...] when Opal is not active? Why can't we keep the old behavior? >>> >>> >>> Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) >>> We where a bit distracted last week so there was no progress on those… soon. >>> >> >> Blocks are now pretty-printed again. >> >> In addition, the new bytecode->AST->source mapping is active, this should >> speed >> up the Debugger a bit and should fix some long standing highlighting bugs. >> >> (But due to the inherent complexity of the whole thing, it fire sure will >> have some >> problems, we will see. The good thing is that problems should be easy to >> debug >> due to the explicit AST/IR based mapping) >> >> Marcus >> > > Yes, for end users, improving the debugger based on Opal should be the next > step. > So what we already have is a first step towards "per AST Node" break/watch/inspect points. Together with the new debugger implementation and the new editor this will allow some quite fancy debugger improvements. Marcus
Re: [Pharo-dev] Block Printing in 3.0
On Jun 19, 2013, at 9:58 AM, Damien Cassou wrote: > On Wed, Jun 19, 2013 at 9:35 AM, Sven Van Caekenberghe wrote: >> Yes, for end users, improving the debugger based on Opal should be the next >> step. > > > when do we activate the new debugger by default? > We really need to take care to not enable too many things at once. For the Debugger, the next step is to enable by default the new Inspector implementation… Marcus
Re: [Pharo-dev] Block Printing in 3.0
2013/6/19 Damien Cassou > On Wed, Jun 19, 2013 at 9:35 AM, Sven Van Caekenberghe > wrote: > > Yes, for end users, improving the debugger based on Opal should be the > next step. > > > when do we activate the new debugger by default? > > We cannot activate both Opal and the new debugger at the same time or we will not know from which of the 2 the highlighting / temp names bugs come from. So in at least a month. Moreover, the new debugger relies also on the new inspectors. So first the new inspectors should be activated by default (I will do that with Camillo in a few days / weeks), then 1 month after the new debugger can be activated. > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > > -- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Asc*
[Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
So, I finished committing and made a last smoke test. VMMaker loads in Pharo2.0 and uses (mostly) Filesystem. I used the rewriting engine to rewrite some parts, and some others I made manually... To sum up: - I created a new version in configuration of cog: 6.5 (in the way I touched ConfigurationOfAsmJit for those related...) - I uploaded this configuration to old MetacelloRepository and MetaRepoForPharo20 in ss3. So you can use either of these: Gofer it squeaksource: 'MetacelloRepository'; configurationOf: 'Cog'; load. Gofer it squeaksource3: 'MetaRepoForPharo20'; configurationOf: 'Cog'; load. - Version 6.5 is intended to be used in Pharo 2.0. (ConfigurationOfCog project version: '6.5') load. - I tested building a pharo vm and a simple cog, *only in mac*. So, further testing is needed :) But it's a start. PharoVMBuilder buildMacOSX32. CogCocoaIOSConfig new generateForRelease; addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); "addThirdpartyLibrary: 'cairo';" generateSources; generate. So a next step is to update the gitorious scripts to use pharo 2.0 + cog 6.5 instead of pharo 1.4 + cog 6.4. And we probably have to review the numbering inside ConfigurationOfCog :). Guille
[Pharo-dev] Barcodes
>About barcodes generation, why don't use Artefact directly ? If you look at the implementation you will see that barcode generation is mostly about implementing the correct encoding (to get a string with 0s and 1s) With this one can easily draw the lines on a form, a morph/canvas or directly in PDF. An easy way now is by using a form, see "BarcodeEAN13 example asForm" and then display this form in PDF via Artefact or use "asMorph openInWorld" Bye T.
Re: [Pharo-dev] A little demo of Cade
tristan could you change the title to: Cade a Thales Framework in Pharo On Jun 19, 2013, at 9:56 AM, Tristan Bourgois wrote: > > > > 2013/6/19 Damien Cassou > On Tue, Jun 18, 2013 at 11:23 PM, Tristan Bourgois > wrote: > > I hope you like this little demo :) And I hope I could make some others :) > > > That's really awesome work Tristan. Nevertheless, the 4th part of the > video is completely black for me. When will Cade be open-sourced :-)? > > > Oh I forgot to put it in the video. Normally you have a view with more than > 4000 shape displaying. > May be I will put it in other demo because this demo is a bit old I made some > upgrade on the framework especially about performance. > > When cade will be open-sourced... Hum good question... I have a lot of > paperwork to do. > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >
Re: [Pharo-dev] A little demo of Cade
Where is the demo/video ? :) 2013/6/19 Stéphane Ducasse > tristan could you change the title to: > Cade a Thales Framework in Pharo > > On Jun 19, 2013, at 9:56 AM, Tristan Bourgois > wrote: > > > > > 2013/6/19 Damien Cassou > >> On Tue, Jun 18, 2013 at 11:23 PM, Tristan Bourgois >> wrote: >> > I hope you like this little demo :) And I hope I could make some others >> :) >> >> >> That's really awesome work Tristan. Nevertheless, the 4th part of the >> video is completely black for me. When will Cade be open-sourced :-)? >> >> > Oh I forgot to put it in the video. Normally you have a view with more > than 4000 shape displaying. > May be I will put it in other demo because this demo is a bit old I made > some upgrade on the framework especially about performance. > > When cade will be open-sourced... Hum good question... I have a lot of > paperwork to do. > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> >> > > -- Best regards, Douaille Erwan
Re: [Pharo-dev] A little demo of Cade
2013/6/19 Stéphane Ducasse > tristan could you change the title to: > Cade a Thales Framework in Pharo > > Done! > On Jun 19, 2013, at 9:56 AM, Tristan Bourgois > wrote: > > > > > 2013/6/19 Damien Cassou > >> On Tue, Jun 18, 2013 at 11:23 PM, Tristan Bourgois >> wrote: >> > I hope you like this little demo :) And I hope I could make some others >> :) >> >> >> That's really awesome work Tristan. Nevertheless, the 4th part of the >> video is completely black for me. When will Cade be open-sourced :-)? >> >> > Oh I forgot to put it in the video. Normally you have a view with more > than 4000 shape displaying. > May be I will put it in other demo because this demo is a bit old I made > some upgrade on the framework especially about performance. > > When cade will be open-sourced... Hum good question... I have a lot of > paperwork to do. > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> >> > >
Re: [Pharo-dev] A little demo of Cade
2013/6/19 Erwan Douaille > Where is the demo/video ? :) > > There : http://www.youtube.com/watch?v=gGlEKtNKl7s :) > > 2013/6/19 Stéphane Ducasse > >> tristan could you change the title to: >> Cade a Thales Framework in Pharo >> >> On Jun 19, 2013, at 9:56 AM, Tristan Bourgois >> wrote: >> >> >> >> >> 2013/6/19 Damien Cassou >> >>> On Tue, Jun 18, 2013 at 11:23 PM, Tristan Bourgois >>> wrote: >>> > I hope you like this little demo :) And I hope I could make some >>> others :) >>> >>> >>> That's really awesome work Tristan. Nevertheless, the 4th part of the >>> video is completely black for me. When will Cade be open-sourced :-)? >>> >>> >> Oh I forgot to put it in the video. Normally you have a view with more >> than 4000 shape displaying. >> May be I will put it in other demo because this demo is a bit old I made >> some upgrade on the framework especially about performance. >> >> When cade will be open-sourced... Hum good question... I have a lot of >> paperwork to do. >> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >>> >>> >> >> > > > -- > Best regards, > > Douaille Erwan >
Re: [Pharo-dev] on:do: for shortcuts?
Why not something like bindKeyCombination:toAction: ? Ben On Jun 19, 2013, at 9:28 AM, Stéphane Ducasse wrote: > excellent > so how do we integrate this change? > > I will chnage the chapter on keymapping :) > > > On Jun 18, 2013, at 9:57 PM, Guillermo Polito > wrote: > >> I prefer the onKeyCombination* because of the following rationale: >> >> - to me a shortcut is the association between a key combination and an action >> - a key combination is a combination of keys :), which is associated with an >> action >> >> Stef, so far I changed the asShortcut => asKeyCombination, following the >> same idea :). >> >> Guille >> >> >> On Tue, Jun 18, 2013 at 8:25 PM, Stéphane Ducasse >> wrote: >> >> On Jun 18, 2013, at 7:21 PM, GOUBIER Thierry wrote: >> >> > The problem with onkeypress, onkeydown, onkeyup is that they are low-level >> > events compared to the shortcuts we are talking about. >> > >> > A shortcut is at least one key, but is usually a key + a modifier or a >> > sequence of key + modifiers (such as the emacs ^X ^C ($x ctrl, $c ctrl). >> > The Keymapping stuff sits a lot higher than the basic keypress events >> > (which do exist as well) and can recognize multi-keys combinations. If you >> > call that onKeyPress:do:, then you loose in the name part of the power of >> > it. >> > >> > Hence the onKeyCombination:do: (but I prefer onShortcut:do:) >> >> onShortcut:do: looks good to me. >> >> Stef >> >> >> > >> > Thierry >> > >> > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Esteban >> > A. Maringolo [emaring...@gmail.com] >> > Date d'envoi : mardi 18 juin 2013 18:14 >> > À : Pharo Development List >> > Objet : Re: [Pharo-dev] on:do: for shortcuts? >> > >> > 2013/6/18 Clément Bera >> > >> >> On Javascript, there are : >> >> >> >> onkeypress >> >> onkeydown >> >> onkeyup >> >> >> >> >> >> I think we should have same API than other languages, especially popular >> >> ones. So 1 of these 3 would be the best for me. >> >> >> >> Why not onKeyPress:do: ? >> > >> > +1 to each of the last two statements. >> > >> > >> >> >> >
[Pharo-dev] Pharo MIDIPlugin
Hi pharoers, It seems that MidiPlugin is not loaded in Pharo2.0. The plugin is present in the repository, but when I try "Smalltalk loadModule: 'MIDIPlugin'" it raises an error. In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" there is no MIDIPlugin. Could someone give me some help to solve this ? Jannik
Re: [Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
Guillermo Polito wrote > VMMaker loads in Pharo2.0 and uses (mostly) Filesystem Nice work! - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Ann-VMMaker-Cog-building-in-Pharo20-tp4694092p4694116.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [ANN]: Pharo x.5
Stéphane Ducasse wrote > I like your browser showing issue. > What does it show? > Because I'm always lost with figbuz :) Yes, I'm starting to get used to fogbugz, but I've found the interface to be counter-intuitive :/ Unfortunately the issue browser is not connected to fogbugz. It simply collects subclasses of SpdPharoIssue, which each have e.g. #number and #description hard-coded, and then for the status, #isFixed which checks to see e.g. whether a certain method which is implemented in the fix is present. It's not a general-purpose browser, but just to make sure that the configuration loaded the correct fixes. Thanks to Spec, it's so easy to build little UI's like this ;) - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-ANN-Pharo-x-5-tp4693932p4694117.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Object>>#if:then:else:
Le 18/06/2013 18:53, Camille Teruel a écrit : >> #someRandomObject if: then: else: thinking of doing a C style >> condition and not using at all the receiver. > > Come on, people are not that stupid ! > And if they really are, no matter what you do, they will write bad code > eventually. It is not a matter of stupidy but analogy as this is the way the brain works. People with C knolwdge will make these mistakes, transposing their C knowloedge to the Smalltak. I did that mistakes. Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] A little demo of Cade
nice! but i don't really understand what happening (yes it is about creating/changing graphical stuff, but that's not enough). :) maybe next time you should add comments while doing something , what you doing. -- Best regards, Igor Stasenko.
[Pharo-dev] you may need to update your configurations
Hello, Since the update #30205, Pharo 3.0 will not be recognized anymore as a Pharo 2.0 platform (from the metacello point of view). It means that if you have specific pharo 2.0 instructions in your configurations and you want to work on Pharo 3.0, you should add pharo 3.0 support in the configuration. For example: spec for: #'pharo1.4.x' version: '1.9'. spec for: #'pharo2.x' version: '1.10'. spec for: #'pharo3.x' version: '1.11'. or : spec for: #'pharo2.x' do: [ ... ] spec for: #'pharo3.x' do: [ ... ] Regards, Christophe. Le 19 juin 2013 à 07:49, Marcus Denker a écrit : > 30205 > - > > 10951 Debugger add new Method class choice dialog should show traits > https://pharo.fogbugz.com/f/cases/10951 > > 10958 Tabs model > https://pharo.fogbugz.com/f/cases/10958 > > 10959 metacelloPlatformAttributes not updated for Pharo3 > https://pharo.fogbugz.com/f/cases/10959 > > 10960 Pass on Tabs > https://pharo.fogbugz.com/f/cases/10960 > > 10961 Fix pluggableTextMorphWithLimits color > https://pharo.fogbugz.com/f/cases/10961 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1147.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.16.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.855.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.199.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.132.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.15.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.39.diff > > smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] A little demo of Cade
2013/6/19 Igor Stasenko > nice! > but i don't really understand what happening (yes it is about > creating/changing graphical stuff, but that's not enough). :) > What's happening is a secret! I should kill you if I told you! :p Seriously, I have some security, licence and confidential problem with speaking of how this framework works. It's very difficult to know on my work the limits of what I can say without have legal problem with Thalès. That's why we are working to push it open-source :) maybe next time you should add comments while doing something , what you > doing. > > -- > Best regards, > Igor Stasenko. > >
[Pharo-dev] [update 3.0] #30208
30208 - 10947 A method in Behavior needs to be recategorized https://pharo.fogbugz.com/f/cases/10947 10948 Add configuration for enable node navigation using arrows https://pharo.fogbugz.com/f/cases/10948 10965 BreakPoints do not work with new AST https://pharo.fogbugz.com/f/cases/10965 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1149.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NodeNavigation-MarcusDenker.41.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1484.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.483.diff
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=linux/247/ 2 regressions found. Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses
Re: [Pharo-dev] you may need to update your configurations
Cool. Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive. Thierry Le 19/06/2013 13:53, Christophe Demarey a écrit : Hello, Since the update #30205, Pharo 3.0 will not be recognized anymore as a Pharo 2.0 platform (from the metacello point of view). It means that if you have specific pharo 2.0 instructions in your configurations and you want to work on Pharo 3.0, you should add pharo 3.0 support in the configuration. For example: spec for: #'pharo1.4.x' version: '1.9'. spec for: #'pharo2.x' version: '1.10'. spec for: #'pharo3.x' version: '1.11'. or : spec for: #'pharo2.x' do: [ ... ] spec for: #'pharo3.x' do: [ ... ] Regards, Christophe. Le 19 juin 2013 à 07:49, Marcus Denker a écrit : 30205 - 10951 Debugger add new Method class choice dialog should show traits https://pharo.fogbugz.com/f/cases/10951 10958 Tabs model https://pharo.fogbugz.com/f/cases/10958 10959 metacelloPlatformAttributes not updated for Pharo3 https://pharo.fogbugz.com/f/cases/10959 10960 Pass on Tabs https://pharo.fogbugz.com/f/cases/10960 10961 Fix pluggableTextMorphWithLimits color https://pharo.fogbugz.com/f/cases/10961 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1147.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.16.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.855.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.199.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.132.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.15.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.39.diff -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=win/247/ 1 regressions found. Tests.Release.ReleaseTest.testObsoleteBehaviors
Re: [Pharo-dev] A little demo of Cade
On 19 June 2013 14:03, Tristan Bourgois wrote: > 2013/6/19 Igor Stasenko >> >> nice! >> but i don't really understand what happening (yes it is about >> creating/changing graphical stuff, but that's not enough). :) > > > What's happening is a secret! I should kill you if I told you! :p Seriously, > I have some security, licence and confidential problem with speaking of how > this framework works. It's very difficult to know on my work the limits of > what I can say without have legal problem with Thalès. > > That's why we are working to push it open-source :) > Yes, because i would like to help you, but i can't because you cannot even tell me where problem is. >> maybe next time you should add comments while doing something , what you >> doing. >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
On 19 June 2013 13:01, Sean P. DeNigris wrote: > Guillermo Polito wrote >> VMMaker loads in Pharo2.0 and uses (mostly) Filesystem > > Nice work! > +1. Just one question: what "(mostly)" stands for? :) Is there parts which still using old stuff? > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-dev-Ann-VMMaker-Cog-building-in-Pharo20-tp4694092p4694116.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
For example, I didn't even try to ensure RiscOSVMMaker port was complete. And since I didn't have a way to test it, who knows? On Wed, Jun 19, 2013 at 3:50 PM, Igor Stasenko wrote: > On 19 June 2013 13:01, Sean P. DeNigris wrote: > > Guillermo Polito wrote > >> VMMaker loads in Pharo2.0 and uses (mostly) Filesystem > > > > Nice work! > > > +1. > > Just one question: what "(mostly)" stands for? > :) > Is there parts which still using old stuff? > > > > > > > - > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Pharo-dev-Ann-VMMaker-Cog-building-in-Pharo20-tp4694092p4694116.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > >
Re: [Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
On Jun 19, 2013, at 3:54 PM, Guillermo Polito wrote: > For example, I didn't even try to ensure RiscOSVMMaker port was complete. And > since I didn't have a way to test it, who knows? > RiscOS is dead since years… it was the OS of the PC like workstation that Archimedes did in the 80ties. (The company became ARM later, the ARM chip was the CPU that they developed for that workstation). So it definitely is more a museum thing… I removed all code mentioning RiscOS from Pharo a long time ago. Marcus > > On Wed, Jun 19, 2013 at 3:50 PM, Igor Stasenko wrote: > On 19 June 2013 13:01, Sean P. DeNigris wrote: > > Guillermo Polito wrote > >> VMMaker loads in Pharo2.0 and uses (mostly) Filesystem > > > > Nice work! > > > +1. > > Just one question: what "(mostly)" stands for? > :) > Is there parts which still using old stuff? > > > > > > > - > > Cheers, > > Sean > > -- > > View this message in context: > > http://forum.world.st/Pharo-dev-Ann-VMMaker-Cog-building-in-Pharo20-tp4694092p4694116.html > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > >
Re: [Pharo-dev] you may need to update your configurations
Le 19 juin 2013 à 14:45, Goubier Thierry a écrit : > Cool. > > Side question: Christophe, are you working on utf8 support for the Monticello > tools? I encountered encoding problems with ZipArchive. Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support. Christophe. [1] https://pharo.fogbugz.com/default.asp?10801 smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] you may need to update your configurations
Le 19/06/2013 16:17, Christophe Demarey a écrit : Le 19 juin 2013 à 14:45, Goubier Thierry a écrit : Cool. Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive. Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support. Ok. Looks nice :) Christophe. [1] https://pharo.fogbugz.com/default.asp?10801 Ouch. Does not bode too well for backporting that to Pharo 2.0. I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way. The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait. By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
Yes, but right now moving from FileDirectory to FileSystem will make harder the merge between VMMaker branches. And cleaning and removing stuff will make it worse... So either we keep the mess or we lose the ability to easily merge :) On Wed, Jun 19, 2013 at 3:58 PM, Marcus Denker wrote: > > On Jun 19, 2013, at 3:54 PM, Guillermo Polito > wrote: > > For example, I didn't even try to ensure RiscOSVMMaker port was complete. > And since I didn't have a way to test it, who knows? > > > RiscOS is dead since years… it was the OS of the PC like workstation that > Archimedes did in the 80ties. > (The company became ARM later, the ARM chip was the CPU that they > developed for that workstation). > > So it definitely is more a museum thing… I removed all code mentioning > RiscOS from Pharo a long time ago. > > > Marcus > > > On Wed, Jun 19, 2013 at 3:50 PM, Igor Stasenko wrote: > >> On 19 June 2013 13:01, Sean P. DeNigris wrote: >> > Guillermo Polito wrote >> >> VMMaker loads in Pharo2.0 and uses (mostly) Filesystem >> > >> > Nice work! >> > >> +1. >> >> Just one question: what "(mostly)" stands for? >> :) >> Is there parts which still using old stuff? >> >> > >> > >> > - >> > Cheers, >> > Sean >> > -- >> > View this message in context: >> http://forum.world.st/Pharo-dev-Ann-VMMaker-Cog-building-in-Pharo20-tp4694092p4694116.html >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > >
Re: [Pharo-dev] you may need to update your configurations
Le 19/06/2013 16:46, Esteban Lorenzano a écrit : important bugfixes can be integrated in 2.0, is not all white and black :) Thanks, you're right of course :) Thierry On Jun 19, 2013, at 4:36 PM, Goubier Thierry wrote: Le 19/06/2013 16:17, Christophe Demarey a écrit : Le 19 juin 2013 à 14:45, Goubier Thierry a écrit : Cool. Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive. Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support. Ok. Looks nice :) Christophe. [1] https://pharo.fogbugz.com/default.asp?10801 Ouch. Does not bode too well for backporting that to Pharo 2.0. I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way. The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait. By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] you may need to update your configurations
Le 19 juin 2013 à 16:36, Goubier Thierry a écrit : > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 > breaks Pharo 2.0 ? Because this change comes from the FileTree branch used fro Pharo3 [1]. This small change avoid to use a deprecated method in Pharo3. It should not be used in Pharo2. [1] https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc1abe0bfa120f3 smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] you may need to update your configurations
important bugfixes can be integrated in 2.0, is not all white and black :) On Jun 19, 2013, at 4:36 PM, Goubier Thierry wrote: > > > Le 19/06/2013 16:17, Christophe Demarey a écrit : >> >> Le 19 juin 2013 à 14:45, Goubier Thierry a écrit : >> >>> Cool. >>> >>> Side question: Christophe, are you working on utf8 support for the >>> Monticello tools? I encountered encoding problems with ZipArchive. >> >> Not at all. There is some work from Nicolas integrated [1] but I'm not >> aware of other work on utf8 support. > > Ok. Looks nice :) > >> Christophe. >> >> [1] https://pharo.fogbugz.com/default.asp?10801 > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or > fighting every few days with 3.0 and knowing that anyway it's not production > ready. I had to cope with 1.4 not being able to handle utf8 in the same way. > > The window for my next serious developpement with Pharo is around 2014, so I > guess I could just sit and wait. > > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 > breaks Pharo 2.0 ? > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >
Re: [Pharo-dev] you may need to update your configurations
Le 19/06/2013 17:01, Christophe Demarey a écrit : Le 19 juin 2013 à 16:36, Goubier Thierry a écrit : By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? Because this change comes from the FileTree branch used fro Pharo3 [1]. This small change avoid to use a deprecated method in Pharo3. It should not be used in Pharo2. [1] https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc1abe0bfa120f3 Thanks. It's just that the latest filetree-core-pharo20 package has MonticelloFileTree-Core-ChristopheDemarey.97 as ancestor :) Probably me messing a merge in my filetree fork. I'm supposed to branch from the pharo20 branch, and I can see your version as well... Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] [Ann] VMMaker + Cog building in Pharo20
On 19 June 2013 16:34, Guillermo Polito wrote: > Yes, but right now moving from FileDirectory to FileSystem will make harder > the merge between VMMaker branches. > And cleaning and removing stuff will make it worse... > > So either we keep the mess or we lose the ability to easily merge :) > i don't think Cog will ever run on riscos in future.. (while on ARM, in general, it will). but it definitely won't use RiscOSVMMaker. I see no reason changing that, especially that Eliot made an effort to use single VMMaker class suitable to be used for building Cog on all platforms. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Barcodes
Hi Olivier. For our label/report generation we do draw the barcodes rather than use a Form. Actually we have a Canvas that adapts to generate PDF so it is all WYSIWYG. Therefore no actual dependency in the PDF generation to any barcode objects. Looking to support Arefact instead of the stuff we have. Not looked at the details of Artefact yet though. TTF in PDF is not so bad... a snippet of what's expected in the output: 6 0 obj << /Type /Font /Subtype /TrueType /BaseFont /Arial /FirstChar 0 /LastChar 255 /Widths 8 0 R /FontDescriptor 9 0 R /Encoding /WinAnsiEncoding >> endobj 9 0 obj << /Type /FontDescriptor /FontName /Arial /Flags 32 /FontBBox [-665 -325 2000 1005] /Ascent 905 /Descent -212 /Leading 0 /ItalicAngle 0 >> endobj 8 0 obj [ 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 277 277 354 556 556 889 666 190 333 333 389 583 277 333 277 277 556 556 556 556 556 556 556 556 556 556 277 277 583 583 583 556 1015 666 666 722 722 666 610 777 722 277 500 666 556 833 722 777 666 777 722 666 610 722 666 943 666 666 610 277 277 277 469 556 333 556 556 500 556 556 277 556 556 222 222 500 222 833 556 556 556 556 333 500 277 556 500 722 500 500 500 333 259 333 583 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 277 333 556 556 556 556 259 556 333 736 370 556 583 333 736 552 399 548 333 333 333 576 537 333 333 333 365 556 833 833 833 610 666 666 666 666 666 666 1000 722 666 666 666 666 277 277 277 277 722 722 777 777 777 777 777 583 777 722 722 722 722 666 666 610 556 556 556 556 556 556 889 500 556 556 556 556 277 277 277 277 556 556 556 556 556 556 556 548 610 556 556 556 556 500 556 500 ] endobj (actually we now use MacRoman encoding as generally works better). All the data there can be gatherted from the FreeType TTF font in Pharo. Just needs to be present on the end-user's pc. A typical PDF reader will do fallbacks as necessary if not present. (not tackled fully embedded fonts yet). Regards, Gary - Original Message - From: Olivier Auverlot To: Pharo Development List Sent: Wednesday, June 19, 2013 6:42 AM Subject: Re: [Pharo-dev] Barcodes Hi Gary, yes, I'm interested by help and pointers about TTF. It's a planned evolution of Artefact. About barcodes generation, why don't use Artefact directly ? You can draw barcodes with the PDFDraw elements (PDFLineElement, PDFRectElement, etc.) and print the document on stickers. In the future, it could be cool to have a Artefact-Elements-Barcodes package :) Best regards Olivier Le 18 juin 2013 à 18:37, Gary Chambers a écrit : Well, hoping to work with Torsten on barcodes in general, given we have support for canvas based drawing of a few formats here at Pinesoft. Also, if Olivier would like some help with TTF in PDFs I can give some pointers etc. Regards, Gary - Original Message - From: Chris Cunningham To: Pharo Development List Sent: Tuesday, June 18, 2013 5:23 PM Subject: Re: [Pharo-dev] Barcodes You should be able to create a form, paint it white, draw on it with a barcode TTF font, export that form to JPEG, and then use that JPEG into Artefact. Not really straight-forward, but it should work. *Note: I've found that writing JPEG's in Pharo, it assumes that the background is BLACK if it isn't isn't specifically painted with something else first. Unlike PNG and GIF, which assume WHITE. -Chris On Tue, Jun 18, 2013 at 1:44 AM, Olivier Auverlot wrote: Hi Torsten, Artefact don't support TTF fonts for the moment but it's planned in futures versions. Best regards Olivier :-) Le 14 juin 2013 à 16:16, Milan Mimica a écrit : You just need a TTF font. Does Artefact support TTF? hpdf does. On 14 June 2013 13:58, Torsten Bergmann wrote: Do we have some barcode stuff available for Pharo? Something "Form" based that can be used with Artefact? Thx T. -- Milan Mimica http://sparklet.sf.net
Re: [Pharo-dev] Pharo MIDIPlugin
Mac OS X? 2013/6/19 jannik laval > Hi pharoers, > > It seems that MidiPlugin is not loaded in Pharo2.0. > The plugin is present in the repository, but when I try "Smalltalk > loadModule: 'MIDIPlugin'" it raises an error. > > In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" there > is no MIDIPlugin. > Could someone give me some help to solve this ? > > Jannik > -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Re: [Pharo-dev] Cloud Hosting Tip
Hey! On 06/18/2013 04:26 PM, Sven Van Caekenberghe wrote: Hi, I am a fan of Amazon AWS's Cloud Services. But it is not perfect. Enter Digital Ocean (https://www.digitalocean.com), an easier to use, simpler cloud hosting provider, that is cheaper and seems faster. You get a raw machine, so you still need some basic Unix admin skills, but apart from that it cannot get much easier. Another one that I have filtered out as very interesting is CloudSigma. KVM based and much more flexible than EC2. regards, Göran
Re: [Pharo-dev] Cloud Hosting Tip
On 19 Jun 2013, at 20:53, Göran Krampe wrote: > Hey! > > On 06/18/2013 04:26 PM, Sven Van Caekenberghe wrote: >> Hi, >> >> I am a fan of Amazon AWS's Cloud Services. But it is not perfect. >> >> Enter Digital Ocean (https://www.digitalocean.com), an easier to use, >> simpler cloud hosting provider, that is cheaper and seems faster. You >> get a raw machine, so you still need some basic Unix admin skills, but >> apart from that it cannot get much easier. > > Another one that I have filtered out as very interesting is CloudSigma. KVM > based and much more flexible than EC2. Yes, those Swiss guys are pretty good. Being in Europe might be important too. Much more comparable to AWS in terms of features. And I see they are SSD based now, very nice. > regards, Göran
Re: [Pharo-dev] [ANN]: Pharo x.5
can you then send me the issues that I should look at :) Stef On Jun 19, 2013, at 1:10 PM, Sean P. DeNigris wrote: > Stéphane Ducasse wrote >> I like your browser showing issue. >> What does it show? >> Because I'm always lost with figbuz :) > > Yes, I'm starting to get used to fogbugz, but I've found the interface to be > counter-intuitive :/ Unfortunately the issue browser is not connected to > fogbugz. It simply collects subclasses of SpdPharoIssue, which each have > e.g. #number and #description hard-coded, and then for the status, #isFixed > which checks to see e.g. whether a certain method which is implemented in > the fix is present. It's not a general-purpose browser, but just to make > sure that the configuration loaded the correct fixes. Thanks to Spec, it's > so easy to build little UI's like this ;) > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-dev-ANN-Pharo-x-5-tp4693932p4694117.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] you may need to update your configurations
> > >> Christophe. >> >> [1] https://pharo.fogbugz.com/default.asp?10801 > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or > fighting every few days with 3.0 and knowing that anyway it's not production > ready. I had to cope with 1.4 not being able to handle utf8 in the same way. Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will). BTW 30 is not that instable. > The window for my next serious developpement with Pharo is around 2014, so I > guess I could just sit and wait. > > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 > breaks Pharo 2.0 ?
Re: [Pharo-dev] Pharo MIDIPlugin
yes. On Jun 19, 2013, at 6:56 PM, NISHIHARA Satoshi wrote: > Mac OS X? > > > 2013/6/19 jannik laval > Hi pharoers, > > It seems that MidiPlugin is not loaded in Pharo2.0. > The plugin is present in the repository, but when I try "Smalltalk > loadModule: 'MIDIPlugin'" it raises an error. > > In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" there is > no MIDIPlugin. > Could someone give me some help to solve this ? > > Jannik > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Re: [Pharo-dev] Pharo MIDIPlugin
In a previous version it was loaded, but I don't remember which one. Jannik On Jun 19, 2013, at 9:24 PM, Stéphane Ducasse wrote: > yes. > > On Jun 19, 2013, at 6:56 PM, NISHIHARA Satoshi wrote: > >> Mac OS X? >> >> >> 2013/6/19 jannik laval >> Hi pharoers, >> >> It seems that MidiPlugin is not loaded in Pharo2.0. >> The plugin is present in the repository, but when I try "Smalltalk >> loadModule: 'MIDIPlugin'" it raises an error. >> >> In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" there is >> no MIDIPlugin. >> Could someone give me some help to solve this ? >> >> Jannik >> >> >> >> -- >> -- >> "NISHIHARA Satoshi" >> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >
Re: [Pharo-dev] you may need to update your configurations
Stéphane, I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members). If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice. Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-) Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane Ducasse [stephane.duca...@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 À : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations > > >> Christophe. >> >> [1] https://pharo.fogbugz.com/default.asp?10801 > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or > fighting every few days with 3.0 and knowing that anyway it's not production > ready. I had to cope with 1.4 not being able to handle utf8 in the same way. Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will). BTW 30 is not that instable. > The window for my next serious developpement with Pharo is around 2014, so I > guess I could just sit and wait. > > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 > breaks Pharo 2.0 ?
Re: [Pharo-dev] you may need to update your configurations
On Jun 19, 2013, at 9:28 PM, GOUBIER Thierry wrote: > Stéphane, > > I'll probably have a look at Nicolas fix anyway, but as it required also a > change to Zinc... then I started to worry. But it may be better than trying > to fix ZipArchive incorrect encoding issues from the outside (by forcing an > utf8 conversion out of the contents of the ZipArchive members). > > If I manage to make sense of it, I'll put a enhancement request in FogBuz > with a slice. > > Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm > fairly dependent on the RPackage infrastructure, and I prefer to wait until > the RPackage refactoring is done ;-) Yes that I can confirm it is wiser. > > Thierry > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane > Ducasse [stephane.duca...@inria.fr] > Date d'envoi : mercredi 19 juin 2013 21:21 > À : Pharo Development List > Objet : Re: [Pharo-dev] you may need to update your configurations > >> >> >>> Christophe. >>> >>> [1] https://pharo.fogbugz.com/default.asp?10801 >> >> Ouch. Does not bode too well for backporting that to Pharo 2.0. >> >> I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or >> fighting every few days with 3.0 and knowing that anyway it's not production >> ready. I had to cope with 1.4 not being able to handle utf8 in the same way. > > Thierry what we can do is the following: >have a look at the fix of nicolas and we can try to add to th 2.0 > batch but we should pay attention >not to introduce other bugs (because I'm afraid it will). > > BTW 30 is not that instable. > > >> The window for my next serious developpement with Pharo is around 2014, so I >> guess I could just sit and wait. >> >> By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 >> breaks Pharo 2.0 ? > >
[Pharo-dev] Fwd: book.pharo-project.org?
Hi guys so what are we doing? Stef Begin forwarded message: > From: "Dale K. Henrichs" > Subject: book.pharo-project.org? > Date: June 19, 2013 9:09:02 PM GMT+02:00 > To: Stéphane Ducasse > > Stef, > > As part of becoming GemTalk Systems we are moving Gemsource, SS3 and > book.pharo-project.org to different servers (gemtalk servers) and I was > curious if you guys still wanted us to continue hosting it? > > It seems that you guys have infrastructure machines now, so I assume that you > could if you are interested. > > We will be switching over next week, so I am in the process of setting up the > servers for this and am just getting around to this image...it's not a big > deal, but if you guys wanted to take over hosting the image, it would be one > less thing for us to worry about:) > > For today, I will move forward assuming that we will host the site and get > things set up... > > Dale
Re: [Pharo-dev] Pharo MIDIPlugin
caseOf: MacOSX 1. MIDIPlugin in Pharo vm requires SerialPlugin (see sqMacMIDI.c). 2. source of SerialPlugin is sqUnixSerial.c (see MacOSConfig>> configureSerialPlugin: in vmmaker-image). 3. at midiInit() of sqMacMIDI.c, it checks the functions of SerialPlugin, but functions below ware missing. serialPortIsOpen serialPortSetControl serialPortNames serialPortCount So midiInit() returns interpreterProxy success: false. it causes primitive error while loading. 2013/05/03, i'd tried to build vm after these ioLoadFunctionFrom 4 functions comment out, and load sound package from PharoExtras, it could use ScorePlayer. yes, checked midi-out only. at least up to Pharo 1.2 MIDIPlugin was loaded. regards. 2013/6/20 jannik.laval > In a previous version it was loaded, but I don't remember which one. > > Jannik > > On Jun 19, 2013, at 9:24 PM, Stéphane Ducasse > wrote: > > yes. > > On Jun 19, 2013, at 6:56 PM, NISHIHARA Satoshi wrote: > > Mac OS X? > > > 2013/6/19 jannik laval > >> Hi pharoers, >> >> It seems that MidiPlugin is not loaded in Pharo2.0. >> The plugin is present in the repository, but when I try "Smalltalk >> loadModule: 'MIDIPlugin'" it raises an error. >> >> In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" there >> is no MIDIPlugin. >> Could someone give me some help to solve this ? >> >> Jannik >> > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > > > > -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Re: [Pharo-dev] Pharo MIDIPlugin
MIDIPlugin is loaded in a prvious PharoVM version (7.zip in the file directory). Here is the system report, probably something has change since this version: === Image - /Users/janniklaval/Desktop/Pharo-2.0/Pharo-2.0.image Pharo2.0 Latest update: #20593 Unnamed Virtual Machine --- /Users/janniklaval/Desktop/Pharo-2.0/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 NBCogit NativeBoost-CogPlugin-IgorStasenko.15 uuid: 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 git://gitorious.org/cogvm/blessed.git Commit: 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 By: Esteban Lorenzano Jenkins build #5922 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 By: Esteban Lorenzano Jenkins build #5922 NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 NBCogit NativeBoost-CogPlugin-IgorStasenko.15 uuid: 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 === Jannik On Jun 19, 2013, at 10:05 PM, NISHIHARA Satoshi wrote: > caseOf: MacOSX > > 1. MIDIPlugin in Pharo vm requires SerialPlugin (see sqMacMIDI.c). > 2. source of SerialPlugin is sqUnixSerial.c (see > MacOSConfig>>configureSerialPlugin: in vmmaker-image). > 3. at midiInit() of sqMacMIDI.c, it checks the functions of SerialPlugin, but > functions below ware missing. > serialPortIsOpen > serialPortSetControl > serialPortNames > serialPortCount > So midiInit() returns interpreterProxy success: false. it causes primitive > error while loading. > > 2013/05/03, i'd tried to build vm after these ioLoadFunctionFrom 4 functions > comment out, and load sound package from PharoExtras, it could use > ScorePlayer. yes, checked midi-out only. > > at least up to Pharo 1.2 MIDIPlugin was loaded. > > regards. > > > > > 2013/6/20 jannik.laval > In a previous version it was loaded, but I don't remember which one. > > Jannik > > On Jun 19, 2013, at 9:24 PM, Stéphane Ducasse > wrote: > >> yes. >> >> On Jun 19, 2013, at 6:56 PM, NISHIHARA Satoshi wrote: >> >>> Mac OS X? >>> >>> >>> 2013/6/19 jannik laval >>> Hi pharoers, >>> >>> It seems that MidiPlugin is not loaded in Pharo2.0. >>> The plugin is present in the repository, but when I try "Smalltalk >>> loadModule: 'MIDIPlugin'" it raises an error. >>> >>> In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" there >>> is no MIDIPlugin. >>> Could someone give me some help to solve this ? >>> >>> Jannik >>> >>> >>> >>> -- >>> -- >>> "NISHIHARA Satoshi" >>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >> > > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Re: [Pharo-dev] you may need to update your configurations
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error. Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception. But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc. Nicolas 2013/6/19 GOUBIER Thierry > Stéphane, > > I'll probably have a look at Nicolas fix anyway, but as it required also a > change to Zinc... then I started to worry. But it may be better than trying > to fix ZipArchive incorrect encoding issues from the outside (by forcing an > utf8 conversion out of the contents of the ZipArchive members). > > If I manage to make sense of it, I'll put a enhancement request in FogBuz > with a slice. > > Yes, I think 30 is not that unstable, like 2.0 was before ... except that > I'm fairly dependent on the RPackage infrastructure, and I prefer to wait > until the RPackage refactoring is done ;-) > > Thierry > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane > Ducasse [stephane.duca...@inria.fr] > Date d'envoi : mercredi 19 juin 2013 21:21 > À : Pharo Development List > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > >> Christophe. > >> > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or > so or fighting every few days with 3.0 and knowing that anyway it's not > production ready. I had to cope with 1.4 not being able to handle utf8 in > the same way. > > Thierry what we can do is the following: > have a look at the fix of nicolas and we can try to add to th 2.0 > batch but we should pay attention > not to introduce other bugs (because I'm afraid it will). > > BTW 30 is not that instable. > > > > The window for my next serious developpement with Pharo is around 2014, > so I guess I could just sit and wait. > > > > By the way, why the change in > MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? > > >
Re: [Pharo-dev] NBOpenGL
>> Are there some resources that are not freed when I saved my image? How can I >> reset them? >> > According to your log, NB cannot get source code of methods. make > sure .source and .changes > files are accessible to image. Ah yes! Thanks Igor! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] you may need to update your configurations
On 19 Jun 2013, at 22:33, Nicolas Cellier wrote: > The change is very light, I applied it almost unchanged on Squeak (can't > remember which version was the first). > The only thing we neeed is to catch an UTF8Error. > > Since in Pharo there are two encoder/decoder hierarchies, and since that of > Zinc is cleaner, I made a bet on future and chose to make UTF8Error a > subclass of existing already Zn Encoding/Decoding exception. > > But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. > So the dependency on Zinc is totally arbitrary and un-necessary right now; it > does not exist in Smalltalk version. > It's just a bet on the future. > For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid > any dependency on Zinc. Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct. Anyway, we have to double check. > Nicolas > > > 2013/6/19 GOUBIER Thierry > Stéphane, > > I'll probably have a look at Nicolas fix anyway, but as it required also a > change to Zinc... then I started to worry. But it may be better than trying > to fix ZipArchive incorrect encoding issues from the outside (by forcing an > utf8 conversion out of the contents of the ZipArchive members). > > If I manage to make sense of it, I'll put a enhancement request in FogBuz > with a slice. > > Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm > fairly dependent on the RPackage infrastructure, and I prefer to wait until > the RPackage refactoring is done ;-) > > Thierry > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane > Ducasse [stephane.duca...@inria.fr] > Date d'envoi : mercredi 19 juin 2013 21:21 > À : Pharo Development List > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > >> Christophe. > >> > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so > > or fighting every few days with 3.0 and knowing that anyway it's not > > production ready. I had to cope with 1.4 not being able to handle utf8 in > > the same way. > > Thierry what we can do is the following: > have a look at the fix of nicolas and we can try to add to th 2.0 > batch but we should pay attention > not to introduce other bugs (because I'm afraid it will). > > BTW 30 is not that instable. > > > > The window for my next serious developpement with Pharo is around 2014, so > > I guess I could just sit and wait. > > > > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 > > breaks Pharo 2.0 ? > > >
Re: [Pharo-dev] Pharo MIDIPlugin
At some point, I remember that there have been a mess when merging changes from interpreter-VM in cog-vm branch. This might have infected the Pharo-branch and this plugin may have been retracted at that time. I'm not really sure, but that would be my starting point for inquiring about MIDIPlugin status (that's what a CI server can serve well). 2013/6/19 jannik.laval > MIDIPlugin is loaded in a prvious PharoVM version (7.zip in the file > directory). > Here is the system report, probably something has change since this > version: > > === > Image > - > /Users/janniklaval/Desktop/Pharo-2.0/Pharo-2.0.image > Pharo2.0 > Latest update: #20593 > Unnamed > > Virtual Machine > --- > /Users/janniklaval/Desktop/Pharo-2.0/Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > NBCogit NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > git://gitorious.org/cogvm/blessed.git Commit: > 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 > By: Esteban Lorenzano Jenkins build #5922 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: > 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 > By: Esteban Lorenzano Jenkins build #5922 > NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > NBCogit NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > === > > Jannik > > On Jun 19, 2013, at 10:05 PM, NISHIHARA Satoshi wrote: > > caseOf: MacOSX > > 1. MIDIPlugin in Pharo vm requires SerialPlugin (see sqMacMIDI.c). > 2. source of SerialPlugin is sqUnixSerial.c (see MacOSConfig>> > configureSerialPlugin: in vmmaker-image). > 3. at midiInit() of sqMacMIDI.c, it checks the functions of SerialPlugin, > but functions below ware missing. > serialPortIsOpen > serialPortSetControl > serialPortNames > serialPortCount > So midiInit() returns interpreterProxy success: false. it causes primitive > error while loading. > > 2013/05/03, i'd tried to build vm after these ioLoadFunctionFrom 4 > functions comment out, and load sound package from PharoExtras, it could > use ScorePlayer. yes, checked midi-out only. > > at least up to Pharo 1.2 MIDIPlugin was loaded. > > regards. > > > > > 2013/6/20 jannik.laval > >> In a previous version it was loaded, but I don't remember which one. >> >> Jannik >> >> On Jun 19, 2013, at 9:24 PM, Stéphane Ducasse >> wrote: >> >> yes. >> >> On Jun 19, 2013, at 6:56 PM, NISHIHARA Satoshi wrote: >> >> Mac OS X? >> >> >> 2013/6/19 jannik laval >> >>> Hi pharoers, >>> >>> It seems that MidiPlugin is not loaded in Pharo2.0. >>> The plugin is present in the repository, but when I try "Smalltalk >>> loadModule: 'MIDIPlugin'" it raises an error. >>> >>> In "Smalltalk listLoadedModules" and "Smalltalk listBuiltinModules" >>> there is no MIDIPlugin. >>> Could someone give me some help to solve this ? >>> >>> Jannik >>> >> >> >> >> -- >> -- >> "NISHIHARA Satoshi" >> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >> >> >> >> > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > > >
Re: [Pharo-dev] you may need to update your configurations
Yes, this part is perfectly correct. It's just that I used ZnInvalidUTF8 in TextConverter which introduces a dependency of TextConverter on Zinc. This only make sense if in the long term we replace those TextConverters by cleaner Zinc encoders/decoders. 2013/6/19 Sven Van Caekenberghe > > On 19 Jun 2013, at 22:33, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > > > The change is very light, I applied it almost unchanged on Squeak (can't > remember which version was the first). > > The only thing we neeed is to catch an UTF8Error. > > > > Since in Pharo there are two encoder/decoder hierarchies, and since that > of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a > subclass of existing already Zn Encoding/Decoding exception. > > > > But we still use the old TextConverter hierarchy in MC, even in Pharo > 3.0. > > So the dependency on Zinc is totally arbitrary and un-necessary right > now; it does not exist in Smalltalk version. > > It's just a bet on the future. > > For a backport to 2.0, I would just use an UTF8Error like in Squeak and > avoid any dependency on Zinc. > > Well ZnInvalidUTF8 is now a full part of Zinc itself > (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your > code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a > dependency, that is correct. > > Anyway, we have to double check. > > > Nicolas > > > > > > 2013/6/19 GOUBIER Thierry > > Stéphane, > > > > I'll probably have a look at Nicolas fix anyway, but as it required also > a change to Zinc... then I started to worry. But it may be better than > trying to fix ZipArchive incorrect encoding issues from the outside (by > forcing an utf8 conversion out of the contents of the ZipArchive members). > > > > If I manage to make sense of it, I'll put a enhancement request in > FogBuz with a slice. > > > > Yes, I think 30 is not that unstable, like 2.0 was before ... except > that I'm fairly dependent on the RPackage infrastructure, and I prefer to > wait until the RPackage refactoring is done ;-) > > > > Thierry > > > > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de > Stéphane Ducasse [stephane.duca...@inria.fr] > > Date d'envoi : mercredi 19 juin 2013 21:21 > > À : Pharo Development List > > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > > > > > >> Christophe. > > >> > > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or > so or fighting every few days with 3.0 and knowing that anyway it's not > production ready. I had to cope with 1.4 not being able to handle utf8 in > the same way. > > > > Thierry what we can do is the following: > > have a look at the fix of nicolas and we can try to add to th > 2.0 batch but we should pay attention > > not to introduce other bugs (because I'm afraid it will). > > > > BTW 30 is not that instable. > > > > > > > The window for my next serious developpement with Pharo is around > 2014, so I guess I could just sit and wait. > > > > > > By the way, why the change in > MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? > > > > > > > > >
Re: [Pharo-dev] you may need to update your configurations
On 19 Jun 2013, at 22:55, Nicolas Cellier wrote: > Yes, this part is perfectly correct. > It's just that I used ZnInvalidUTF8 in TextConverter which introduces a > dependency of TextConverter on Zinc. OK, but technically, it is a dependency on Zinc-Character-Encoding-Core, which is independent of the Zinc HTTP code itself. Just like Zinc-Resource-Meta-Core (containing ZnUrl and ZnMimeType) is independent of the HTTP code proper. These sub packages where created specifically to break unwanted dependencies, as requested by Pavel et al. > This only make sense if in the long term we replace those TextConverters by > cleaner Zinc encoders/decoders. Yes, that is the idea, eventually. But never in 2.0. > 2013/6/19 Sven Van Caekenberghe > > On 19 Jun 2013, at 22:33, Nicolas Cellier > wrote: > > > The change is very light, I applied it almost unchanged on Squeak (can't > > remember which version was the first). > > The only thing we neeed is to catch an UTF8Error. > > > > Since in Pharo there are two encoder/decoder hierarchies, and since that of > > Zinc is cleaner, I made a bet on future and chose to make UTF8Error a > > subclass of existing already Zn Encoding/Decoding exception. > > > > But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. > > So the dependency on Zinc is totally arbitrary and un-necessary right now; > > it does not exist in Smalltalk version. > > It's just a bet on the future. > > For a backport to 2.0, I would just use an UTF8Error like in Squeak and > > avoid any dependency on Zinc. > > Well ZnInvalidUTF8 is now a full part of Zinc itself > (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your > code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, > that is correct. > > Anyway, we have to double check. > > > Nicolas > > > > > > 2013/6/19 GOUBIER Thierry > > Stéphane, > > > > I'll probably have a look at Nicolas fix anyway, but as it required also a > > change to Zinc... then I started to worry. But it may be better than trying > > to fix ZipArchive incorrect encoding issues from the outside (by forcing an > > utf8 conversion out of the contents of the ZipArchive members). > > > > If I manage to make sense of it, I'll put a enhancement request in FogBuz > > with a slice. > > > > Yes, I think 30 is not that unstable, like 2.0 was before ... except that > > I'm fairly dependent on the RPackage infrastructure, and I prefer to wait > > until the RPackage refactoring is done ;-) > > > > Thierry > > > > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane > > Ducasse [stephane.duca...@inria.fr] > > Date d'envoi : mercredi 19 juin 2013 21:21 > > À : Pharo Development List > > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > > > > > >> Christophe. > > >> > > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so > > > or fighting every few days with 3.0 and knowing that anyway it's not > > > production ready. I had to cope with 1.4 not being able to handle utf8 in > > > the same way. > > > > Thierry what we can do is the following: > > have a look at the fix of nicolas and we can try to add to th 2.0 > > batch but we should pay attention > > not to introduce other bugs (because I'm afraid it will). > > > > BTW 30 is not that instable. > > > > > > > The window for my next serious developpement with Pharo is around 2014, > > > so I guess I could just sit and wait. > > > > > > By the way, why the change in > > > MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? > > > > > > > > >
Re: [Pharo-dev] you may need to update your configurations
Certainly not in 2.0 Even in 3.0, this will be hard because this mean a big clean-up of Stream mess (Xtreams?) 2013/6/19 Sven Van Caekenberghe > > On 19 Jun 2013, at 22:55, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > > > Yes, this part is perfectly correct. > > It's just that I used ZnInvalidUTF8 in TextConverter which introduces a > dependency of TextConverter on Zinc. > > OK, but technically, it is a dependency on Zinc-Character-Encoding-Core, > which is independent of the Zinc HTTP code itself. Just like > Zinc-Resource-Meta-Core (containing ZnUrl and ZnMimeType) is independent of > the HTTP code proper. These sub packages where created specifically to > break unwanted dependencies, as requested by Pavel et al. > > > This only make sense if in the long term we replace those TextConverters > by cleaner Zinc encoders/decoders. > > Yes, that is the idea, eventually. But never in 2.0. > > > 2013/6/19 Sven Van Caekenberghe > > > > On 19 Jun 2013, at 22:33, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > > > > > The change is very light, I applied it almost unchanged on Squeak > (can't remember which version was the first). > > > The only thing we neeed is to catch an UTF8Error. > > > > > > Since in Pharo there are two encoder/decoder hierarchies, and since > that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error > a subclass of existing already Zn Encoding/Decoding exception. > > > > > > But we still use the old TextConverter hierarchy in MC, even in Pharo > 3.0. > > > So the dependency on Zinc is totally arbitrary and un-necessary right > now; it does not exist in Smalltalk version. > > > It's just a bet on the future. > > > For a backport to 2.0, I would just use an UTF8Error like in Squeak > and avoid any dependency on Zinc. > > > > Well ZnInvalidUTF8 is now a full part of Zinc itself > (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your > code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a > dependency, that is correct. > > > > Anyway, we have to double check. > > > > > Nicolas > > > > > > > > > 2013/6/19 GOUBIER Thierry > > > Stéphane, > > > > > > I'll probably have a look at Nicolas fix anyway, but as it required > also a change to Zinc... then I started to worry. But it may be better than > trying to fix ZipArchive incorrect encoding issues from the outside (by > forcing an utf8 conversion out of the contents of the ZipArchive members). > > > > > > If I manage to make sense of it, I'll put a enhancement request in > FogBuz with a slice. > > > > > > Yes, I think 30 is not that unstable, like 2.0 was before ... except > that I'm fairly dependent on the RPackage infrastructure, and I prefer to > wait until the RPackage refactoring is done ;-) > > > > > > Thierry > > > > > > > > > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de > Stéphane Ducasse [stephane.duca...@inria.fr] > > > Date d'envoi : mercredi 19 juin 2013 21:21 > > > À : Pharo Development List > > > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > > > > > > > > > >> Christophe. > > > >> > > > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year > or so or fighting every few days with 3.0 and knowing that anyway it's not > production ready. I had to cope with 1.4 not being able to handle utf8 in > the same way. > > > > > > Thierry what we can do is the following: > > > have a look at the fix of nicolas and we can try to add to th > 2.0 batch but we should pay attention > > > not to introduce other bugs (because I'm afraid it will). > > > > > > BTW 30 is not that instable. > > > > > > > > > > The window for my next serious developpement with Pharo is around > 2014, so I guess I could just sit and wait. > > > > > > > > By the way, why the change in > MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? > > > > > > > > > > > > > > > > > >
Re: [Pharo-dev] you may need to update your configurations
Thierry, File names are not necessarily unique in the Monticello universe, if the UUIDs match then they are the same ancestor... Dale - Original Message - | From: "Goubier Thierry" | To: "Pharo Development List" | Sent: Wednesday, June 19, 2013 8:15:48 AM | Subject: Re: [Pharo-dev] you may need to update your configurations | | | | Le 19/06/2013 17:01, Christophe Demarey a écrit : | > | > Le 19 juin 2013 à 16:36, Goubier Thierry a écrit : | > | >> By the way, why the change in | >> MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? | > | > Because this change comes from the FileTree branch used fro Pharo3 | > [1]. | > This small change avoid to use a deprecated method in Pharo3. | > It should not be used in Pharo2. | > | > [1] | > https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc1abe0bfa120f3 | | Thanks. It's just that the latest filetree-core-pharo20 package has | MonticelloFileTree-Core-ChristopheDemarey.97 as ancestor :) | | Probably me messing a merge in my filetree fork. I'm supposed to | branch | from the pharo20 branch, and I can see your version as well... | | Thierry | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 | |
Re: [Pharo-dev] Pharo MIDIPlugin
So, I tried to load Phratch in multiple VM versions. MIDIPlugins does not load if I use a one-click. Else, If I use the vm + an image, it works fine. Where is the problem ? Here is the report of the latest one-click i found on pharo-project.org: === Image - /Users/janniklaval/Desktop/Pharo2.0 3.app/Contents/Resources/Pharo2.0.image Pharo2.0 Latest update: #20607 Unnamed Virtual Machine --- /Users/janniklaval/Desktop/Pharo2.0 3.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano Jenkins build #14535 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano Jenkins build #14535 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 Loaded VM Modules - B2DPlugin VMMaker-oscog-EstebanLorenzano.236 (i) BitBltPlugin VMMaker-oscog-EstebanLorenzano.236 (i) FilePlugin VMMaker-oscog-EstebanLorenzano.236 (i) LargeIntegers v1.5 VMMaker-oscog-EstebanLorenzano.236 (i) LocalePlugin 9 June 2005 (e) MiscPrimitivePlugin VMMaker-oscog-EstebanLorenzano.236 (i) SecurityPlugin VMMaker-oscog-EstebanLorenzano.236 (i) VM Built-in Modules --- ADPCMCodecPlugin VMMaker-oscog-EstebanLorenzano.236 (i) AioPlugin VMConstruction-Plugins-AioPlugin-EstebanLorenzano.13 (i) B2DPlugin VMMaker-oscog-EstebanLorenzano.236 (i) BMPReadWriterPlugin VMMaker-oscog-EstebanLorenzano.236 (i) BitBltPlugin VMMaker-oscog-EstebanLorenzano.236 (i) ClipboardExtendedPlugin VMMaker-oscog-EstebanLorenzano.236 (i) DSAPrims VMMaker-oscog-EstebanLorenzano.236 (i) DropPlugin VMMaker-oscog-EstebanLorenzano.236 (i) FFTPlugin VMMaker-oscog-EstebanLorenzano.236 (i) FilePlugin VMMaker-oscog-EstebanLorenzano.236 (i) FloatArrayPlugin VMMaker-oscog-EstebanLorenzano.236 (i) GeniePlugin v2.0 13 March 2013 VMMaker-oscog-EstebanLorenzano.236 (i) HostWindowPlugin VMMaker-oscog-EstebanLorenzano.236 (i) JPEGReadWriter2Plugin VMMaker-oscog-EstebanLorenzano.236 (i) JPEGReaderPlugin VMMaker-oscog-EstebanLorenzano.236 (i) Klatt VMMaker-oscog-EstebanLorenzano.236 (i) LargeIntegers v1.5 VMMaker-oscog-EstebanLorenzano.236 (i) Matrix2x3Plugin VMMaker-oscog-EstebanLorenzano.236 (i) MiscPrimitivePlugin VMMaker-oscog-EstebanLorenzano.236 (i) NativeBoostPlugin NativeBoost-CogPlugin-EstebanLorenzano.18 (i) RePlugin VMMaker-oscog-EstebanLorenzano.236 (i) SecurityPlugin VMMaker-oscog-EstebanLorenzano.236 (i) SocketPlugin VMMaker-oscog-EstebanLorenzano.236 (i) SoundCodecPrims VMMaker-oscog-EstebanLorenzano.236 (i) SoundPlugin VMMaker-oscog-EstebanLorenzano.236 (i) StarSqueakPlugin VMMaker-oscog-EstebanLorenzano.236 (i) SurfacePlugin Mar 13 2013 (i) UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-eem.32 (i) ZipPlugin VMMaker-oscog-EstebanLorenzano.236 (i) === On Jun 19, 2013, at 10:40 PM, Nicolas Cellier wrote: > At some point, I remember that there have been a mess when merging changes > from interpreter-VM in cog-vm branch. > This might have infected the Pharo-branch and this plugin may have been > retracted at that time. > I'm not really sure, but that would be my starting point for inquiring about > MIDIPlugin status (that's what a CI server can serve well). > > > 2013/6/19 jannik.laval > MIDIPlugin is loaded in a prvious PharoVM version (7.zip in the file > directory). > Here is the system report, probably something has change since this version: > > === > Image > - > /Users/janniklaval/Desktop/Pharo-2.0/Pharo-2.0.image > Pharo2.0 > Latest update: #20593 > Unnamed > > Virtual Machine > --- > /Users/janniklaval/Desktop/Pharo-2.0/Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > NBCogit NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > git://gitorious.org/cogvm/blessed.git Commit: > 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 By: > Esteban Lorenzano Jenkins build #5922 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: > 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 By: > Esteban Lorenzano Jenkins build #5922 > NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: > 44b6b681-38f1-4a9e-b6ee-8769b499576a Dec 12 2012 > NBCogit N
