- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] 17 GSoC projects accepted

by Guillermo Polito

On Tue, May 28, 2013 at 2:14 PM, Clara Allende <clari.allende(a)gmail.com>wrote: > Lots of women! > Yes, that's dangerous.. > and Argentinians! > And this even more...... > This is really great news :) > > Congrats everyone! > haha, yeah, congrats for all the work so far and now let's have some cool projects :) > > > On 28 May 2013 08:43, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Sven Van Caekenberghe-2 wrote >> > Great news ! Thanks for the effort, Janko. >> >> +1. These are all exciting and valuable projects! I can't wait to see (and >> play with) the results :) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Pharo-dev-17-GSoC-projects-accepted-tp4690335p4690395… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

May 28, 2013

Re: [Pharo-dev] [Pharo-users] 17 GSoC projects accepted

by Clara Allende

Lots of women! and Argentinians! This is really great news :) Congrats everyone! On 28 May 2013 08:43, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > Great news ! Thanks for the effort, Janko. > > +1. These are all exciting and valuable projects! I can't wait to see (and > play with) the results :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-dev-17-GSoC-projects-accepted-tp4690335p4690395… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 28, 2013

Re: [Pharo-dev] [ANN] SmalltalkHub update

by Sven Van Caekenberghe

On 28 May 2013, at 11:28, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > On Tue, May 28, 2013 at 9:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > And the best change is under the hood ;-) > > Yes! And Pharo 1.4 running in a StackVM has been replaced by Pharo 2.0 running in a CogVM. That is worth some serious performance points as well, indeed. BTW, I see that you have enabled gzip compression server side as well, using Zinc ? That means you are using a very recent version of Zn, which one ? Anyway, more performance improvements are underway. Sven

May 28, 2013

Re: [Pharo-dev] [Pharo-users] 17 GSoC projects accepted

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Great news ! Thanks for the effort, Janko. +1. These are all exciting and valuable projects! I can't wait to see (and play with) the results :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-17-GSoC-projects-accepted-tp4690335p4690395… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 28, 2013

[update 3.0] #30172

by Marcus Denker

30172 ----- 10544 Fixes to RING meta model https://pharo.fogbugz.com/f/cases/10544 10771 SpecDebugger calls wrong spec https://pharo.fogbugz.com/f/cases/10771 10772 Smalltalk condenseChanges broken https://pharo.fogbugz.com/f/cases/10772 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.2… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Environment-Marcu… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-MarcusDenker.1…

May 28, 2013

Re: [Pharo-dev] [Ann] New TxText version 1.0

by Camillo Bruni

On 2013-05-28, at 11:13, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/28 Camillo Bruni <camillobruni(a)gmail.com> > >> Jenkins is not happy, https://ci.inria.fr/pharo-contribution/job/TxText/:P >> >> Denis, would it be possible to add a #stable and maybe a #development >> version to the >> configuration? >> >> > I will make it at evening. > Before you migrate to new CI infrastructure I received mails about TxText > problems. > But now it is not happen. How I can fix it? You can add yourself to the mail notification: https://ci.inria.fr/pharo-contribution/job/TxText/configure if you aren't a member yet, register here: http://ci.inria.fr and add yourself to pharo-contribution, we will enable you to be an admin.

May 28, 2013

Re: [Pharo-dev] [ANN] SmalltalkHub update

by Damien Cassou

On Tue, May 28, 2013 at 9:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > And the best change is under the hood ;-) Yes! And Pharo 1.4 running in a StackVM has been replaced by Pharo 2.0 running in a CogVM. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 28, 2013

Re: [Pharo-dev] [Esug-list] [ANN] SmalltalkHub update

by Damien Cassou

On Tue, May 28, 2013 at 10:11 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > Does that mean that we will be able to delete projects too ? How about > renaming ? deleting a project which belongs to an individual is already possible. Deleting a project which belongs to a team will work as soon as the new changes get deployed. For the renaming, fill an issue in the tracker: http://code.google.com/p/smalltalk-hub/issues/list -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 28, 2013

Re: [Pharo-dev] [Ann] New TxText version 1.0

by Denis Kudriashov

2013/5/28 Camillo Bruni <camillobruni(a)gmail.com> > Jenkins is not happy, https://ci.inria.fr/pharo-contribution/job/TxText/:P > > Denis, would it be possible to add a #stable and maybe a #development > version to the > configuration? > > I will make it at evening. Before you migrate to new CI infrastructure I received mails about TxText problems. But now it is not happen. How I can fix it? > On 2013-05-28, at 08:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2013/5/28 Tudor Girba <tudor(a)tudorgirba.com> > > > >> Hi, > >> > >> I found the issue: the url from the Gofer script was wrong :). > >> > >> Here is the correct one: > >> Gofer it > >> url: 'http://www.smalltalkhub.com/mc/sig/TxText/main'; > >> package: 'ConfigurationOfTxText'; > >> load. > >> > > > > It is true of course. But I can't understand why it works for me with ' > > http://www.smalltalkhub.com/#!/~sig/TxText'; url > > Any way thank's for this fix > > > >> > >> ((Smalltalk at: #ConfigurationOfTxText) project version: '1.0') load: > >> #('ALL'). > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On May 27, 2013, at 6:44 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > >> wrote: > >> > >>> 2013/5/27 Tudor Girba <tudor(a)tudorgirba.com> > >>> I tried to load it, but could not because in the sig repository, the > >> latest version of the configuration is still 0.6. > >>> > >>> > >>> It works for me. I use Pharo 2.0 on Windows 7. > >>> And you can see by webbrowser all versions exist at smalltalkhub > >> repository http://www.smalltalkhub.com/#!/~sig/TxText > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> On May 26, 2013, at 11:09 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > >> wrote: > >>> > >>>> Hello. > >>>> > >>>> I finish edit validation logic. So new version 1.0 is available: > >>>> > >>>> Gofer it > >>>> url: 'http://www.smalltalkhub.com/#!/~sig/TxText'; > >>>> package: 'ConfigurationOfTxText'; > >>>> load. > >>>> > >>>> ((Smalltalk at: #ConfigurationOfTxText) project version: '1.0') load: > >>>> #('ALL'). > >>>> > >>>> TxEditValidator is introduced for TxEditor. It validates changes > >> performed by given block. > >>>> It asks editor to try changes from this block. And if changed text > >> satisfied text spec validator executes given block to apply changes. > >>>> > >>>> Few text specs implemented: > >>>> -TxAnyTextSpec > >>>> -TxDigitalTextSpec > >>>> -TxDecimalTextSpec > >>>> > >>>> More example of text specs are at TxTextMorph class side: > >>>> - mask with digits only > >>>> - smart numbers which accept only decimal numbers: > >>>> > >>>> m := TxTextMorph new. > >>>> m editDecorator: TxSingleLineEditDecorator smartNumbers. > >>>> m textSpec: (TxDecimalTextSpec maxDecimalDigits: 3). > >>>> m newTextContents: '10000000'. > >>>> m addCursor. > >>>> m beEditable. > >>>> m openInHand > >>>> > >>>> Best regards. > >>>> Denis. > >>>> > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Problem solving efficiency grows with the abstractness level of > problem > >> understanding." > >>> > >>> > >>> > >>> > >>> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Quality cannot be an afterthought." > >> > >> > >> > > >

May 28, 2013

Re: [Pharo-dev] TxText new version 0.8

by Sven Van Caekenberghe

On 23 May 2013, at 10:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 23 May 2013, at 10:12, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> Hmm, there are different views possible on this. >>> >> Absolutely! >> >>> We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open. >>> >> That's my only point. Having tests packaged separately just opens the possibility to make things smaller. >> >>> I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable. >>> >> agreed. >> >>> I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO. >>> >> That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit. > > That is a cool trick ! > > So cool that I want to make that into a general purpose Zn handler (totally optional and on localhost only of course) ;-) And so I did: --- Name: Zinc-HTTP-SvenVanCaekenberghe.363 Author: SvenVanCaekenberghe Time: 28 May 2013, 10:38:03 am UUID: a1fa8795-eb44-4812-81e7-3da28fa9bda9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.362 Implemented ZnTestRunnerDelegate (original idea by Norbert Hartl - Thx) Minor optimalization to ZnUtils class>>#nextPutAll:on: --- $ curl http://localhost:1701/sunit/ZnUtilsTests 15 run, 15 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes $ curl http://localhost:1701/sunit/ZnUtilsTests/testBase64 1 run, 1 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes The above are 200 responses, a failure will be a 500 response. With specifically written tests this could be quite useful for monit checks. Sven PS: The service is off by default, and when on only exposed to localhost, don't change this without thinking about the consequences ! >> Norbert >>> On 23 May 2013, at 09:43, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> On 2013-05-23, at 09:35, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>>> Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni(a)gmail.com>: >>>>> >>>>>>>>> >>>>>>>> technically yes, but you do not need many things to run the code: >>>>>>>> - class comments >>>>>>>> - method comments >>>>>>>> - any documentation in general >>>>>>>> >>>>>>> >>>>>>> And I don't have it at production because I don't have changes file here. >>>>>>> >>>>>>> >>>>>>>> yet you load them. so I wonder if it makes sense to even load tests >>>>>>>> separately? >>>>>>>> >>>>>>> >>>>>>> It make sense when you try to reduce production image size. And loading >>>>>>> only required packages (without tests) works well. Why change it? >>>>>> >>>>>> I know that this scheme is in use, but why? why do I have to reduce the size >>>>>> of a production image? from how many to many megabytes? It might make sense >>>>>> for moose, but none of the other projects. Do you really care if the image is >>>>>> 35 instead of 25MB? To me this argument sounds invalid :/ >>>>>> >>>>> I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. >>>>> Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason. >>>> >>>> So I conclude that for a production ready image you want to strip out as much as possible: >>>> - tests >>>> - comments (luckily in the changes file...) >>>> - source code (luckily in the changes file...) >>>> - monticello metadata (which was around 5MB or so, did anybody care?) >>>> - font files that linger around (also around 2MB, and also mostly ignored) >>>> >>>> which sort of makes sense, however for that you will need a custom tool, which is orthogonal >>>> to being able to load tests in a separate package. And the test only contribute to the static >>>> code base, whereas in a live production environment I would expect to have more live objects >>>> (I am guessing here)?. >>>> >>>> So for a production environment, if you want to get these small MB savings on the image you >>>> need a decent script. I would really like to have real numbers on how much the tests contribute >>>> to the total size. >>> >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >> >> >

May 28, 2013