June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Refactoring File Package

by Ben Coman

On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Actually we just want to have a kind of split in: > > - essential > - non-essential I guess you have scripts outside the image to shrink the image and then bootstrap it. However these are not necessarily visible to everyone and I am wondering once the bootstrap goal is achieved you will handle the entropy of ongoing development by many others accidentally introducing dependencies that breaks the bootstrap? Also what I have seen is classes being moved out of their current packaging (sorry I forget the details, but I think it was moved out of System) into a new top-level package, which I think loses something in structure and might pollute the top-level packages. So considering the recent discussion of package tags, I wonder if somehow we could have a "Bootstrap" tag and realtime critics that complain if Bootstrap-tagged-class references any non-Bootstrap-tagged-class. There might even be several levels of Bootstrap tags. This would improve ongoing visibility of the bootstrap structure and help the rest of us to not shoot it in the foot. I wonder also if tags might also be extended to method protocols, so you can have a method with the "accessors" tag and also the "bootstrap" tag, so that even a Bootstrap-tagged-class can be further minimised by the methods it needs during bootstrap. Otherwise I guess to minimise the methods in a Bootstrap-tagged-class, later extension by another package could not add methods to the "accessors" protocol. P.S. I know I do a lot of wondering, and of course divergent thought is easier than concrete answers. cheers -ben > > Then the bootstrap will include essential packages at the beginning and > non-essential will be just loaded on top. > > The rationale is: the smaller the kernel, the fastest the bootstrap, and > with it the feedback loop we have. > > That's why I was working on the File abstractions, and splitting some other > kernel package. > > El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo <stepharo(a)free.fr> > escribiÃ³: >> >> Yes sven but with guille we are working on a really small kernel. So we >> can duplicate just the classes we need but I would prefer not >> but we can do it. The size is important for us because it takes time to >> bootstrap. >> >> Stef >> >> Le 5/6/15 19:06, Sven Van Caekenberghe a Ã©crit : >> >> On 05 Jun 2015, at 18:43, Guillermo Polito <guillermopolito(a)gmail.com> >> >> wrote: >> >> >> >> The only encoder that makes a bit of noise to me is the ZnByteEncoder >> >> that contains a lot of mapping tables for mostly unused encodings >> > 67 encoding specifications, each a 128 array. The method constant is >> > shared when used. >> > In the beginning there were only a couple, one day I added many more, >> > some people need them. >> > For me, the cost is reasonable. >> > >> >> (plus methods with metadata to recreate them)... >> > That is just two method (which is pretty cool, I love spec based >> > programming). >> > >> >> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe >> >> <sven(a)stfx.eu> escribiÃ³: >> >> >> >>> On 05 Jun 2015, at 18:20, stepharo <stepharo(a)free.fr> wrote: >> >>> >> >>> Sven >> >>> >> >>> we were talking about splitting your package into two parts :) >> >>> Would you be ok to get the basic encoders in a separate package? >> >> Zinc-Character-Encoding is already a separate package, it depends on >> >> nothing. >> >> Zinc-Resource-Meta is next up (containing URL and Mime-Type). >> >> Both are completely independent of any HTTP stuff. >> >> All this is by design. >> >> >> >> You probably mean that you want a separate config ? Right now they are >> >> just a groups. >> >> >> >>> We were also thinking that NullEncoder could be called AsciiEncoder? >> >> Maybe, maybe not, let me think about that a bit. >> >> >> >>> Stef >> >>> >> >>>>> On 05 Jun 2015, at 18:09, Damien Cassou <damien.cassou(a)inria.fr> >> >>>>> wrote: >> >>>>> >> >>>>> >> >>>>> Guillermo Polito <guillermopolito(a)gmail.com> writes: >> >>>>> >> >>>>>> Well, I made a cleaner implementation at the side with >> >>>>>> >> >>>>>> - a simple File object that is a sequential File as we all know >> >>>>>> - a binary File stream on top of it that is composable with Zn >> >>>>>> encoders and >> >>>>>> other decorators >> >>>>>> - a new interface to access Stdio streams >> >>>>> that's really good news Guillermo. >> >>>> Yes it is (need time to look at this in detail) >> >>>> >> >>>>> Is it ok to make File reading depend >> >>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping >> >>>>> harder? >> >>>> It does not depend on the HTTP part, but on the Encoding part below >> >>>> it, so that should be OK. >> >>>> >> >>>>> -- >> >>>>> Damien Cassou >> >>>>> http://damiencassou.seasidehosting.st >> >>>>> >> >>>>> "Success is the ability to go from one failure to another without >> >>>>> losing enthusiasm." --Winston Churchill >> >>>>> >> >>>> >> >>> >> >> >> > >> > >> >> >

June 6, 2015

Re: [Pharo-dev] Refactoring File Package

by Guillermo Polito

Actually we just want to have a kind of split in: - essential - non-essential Then the bootstrap will include essential packages at the beginning and non-essential will be just loaded on top. The rationale is: the smaller the kernel, the fastest the bootstrap, and with it the feedback loop we have. That's why I was working on the File abstractions, and splitting some other kernel package. El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo <stepharo(a)free.fr> escribiÃ³: > Yes sven but with guille we are working on a really small kernel. So we > can duplicate just the classes we need but I would prefer not > but we can do it. The size is important for us because it takes time to > bootstrap. > > Stef > > Le 5/6/15 19:06, Sven Van Caekenberghe a Ã©crit : > >> On 05 Jun 2015, at 18:43, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> > >> The only encoder that makes a bit of noise to me is the ZnByteEncoder > that contains a lot of mapping tables for mostly unused encodings > > 67 encoding specifications, each a 128 array. The method constant is > shared when used. > > In the beginning there were only a couple, one day I added many more, > some people need them. > > For me, the cost is reasonable. > > > >> (plus methods with metadata to recreate them)... > > That is just two method (which is pretty cool, I love spec based > programming). > > > >> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe < > sven(a)stfx.eu> escribiÃ³: > >> > >>> On 05 Jun 2015, at 18:20, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> Sven > >>> > >>> we were talking about splitting your package into two parts :) > >>> Would you be ok to get the basic encoders in a separate package? > >> Zinc-Character-Encoding is already a separate package, it depends on > nothing. > >> Zinc-Resource-Meta is next up (containing URL and Mime-Type). > >> Both are completely independent of any HTTP stuff. > >> All this is by design. > >> > >> You probably mean that you want a separate config ? Right now they are > just a groups. > >> > >>> We were also thinking that NullEncoder could be called AsciiEncoder? > >> Maybe, maybe not, let me think about that a bit. > >> > >>> Stef > >>> > >>>>> On 05 Jun 2015, at 18:09, Damien Cassou <damien.cassou(a)inria.fr> > wrote: > >>>>> > >>>>> > >>>>> Guillermo Polito <guillermopolito(a)gmail.com> writes: > >>>>> > >>>>>> Well, I made a cleaner implementation at the side with > >>>>>> > >>>>>> - a simple File object that is a sequential File as we all know > >>>>>> - a binary File stream on top of it that is composable with Zn > encoders and > >>>>>> other decorators > >>>>>> - a new interface to access Stdio streams > >>>>> that's really good news Guillermo. > >>>> Yes it is (need time to look at this in detail) > >>>> > >>>>> Is it ok to make File reading depend > >>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping > harder? > >>>> It does not depend on the HTTP part, but on the Encoding part below > it, so that should be OK. > >>>> > >>>>> -- > >>>>> Damien Cassou > >>>>> http://damiencassou.seasidehosting.st > >>>>> > >>>>> "Success is the ability to go from one failure to another without > >>>>> losing enthusiasm." --Winston Churchill > >>>>> > >>>> > >>> > >> > > > > > > >

June 6, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 443652: 50064

by stepharo

I agree. Now it can only work if people create issues. Stef Le 30/5/15 17:50, Ben Coman a Ã©crit : > On Mon, May 25, 2015 at 5:17 PM, GitHub <noreply(a)github.com> wrote: >> Log Message: >> ----------- >> 50064 >> 15605 Update Rubric >> https://pharo.fogbugz.com/f/cases/15605 >> >> http://files.pharo.org/image/50/50064.zip >> > I feel we have a hole in our process where integration of external > packages is a bit opaque. Presumably there can be several Issues > encompassed by one "Update External Package" integration, but how do > we find which they are? Ideally all such issues would be > automatically listed (maybe being attached as sub-case to > integrated-Issue, or maybe by being marked "fixed upstream" and listed > the integrated-issue.) Perhaps as a stop gap the comment on the > integrated Slice/Configuration could be shown in this log. At least a > chance to manually list several integrated imaged. > > P.S. I know this infrastructure usually falls to Esteban and he seems > plenty busy with important stuff at the moment, so please just > consider this low priority feedback. > cheers -ben > >

June 6, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50093 Home: https://github.com/pharo-project/pharo-core

June 6, 2015

[pharo-project/pharo-core] 7fa50a: 50093

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7fa50a3e5a4b7440ac7e0779cbb10b92180cec62 https://github.com/pharo-project/pharo-core/commit/7fa50a3e5a4b7440ac7e0779… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-06 (Sat, 06 Jun 2015) Changed paths: M Monticello-Tests.package/MCStReaderTest.class/instance/util/methodWithStyle.st M Monticello.package/MCMethodDefinition.class/instance/printing/summary.st M Monticello.package/MCStReader.class/instance/evaluating/loadDefinitions.st M Monticello.package/MCStReader.class/instance/reading/classDefinitionFrom_.st M Monticello.package/MCStReader.class/instance/reading/classInstVarNamesFor_.st M Monticello.package/MCStReader.class/instance/reading/commentFor_.st M Monticello.package/MCStReader.class/instance/reading/commentStampFor_.st M Monticello.package/MCStReader.class/instance/reading/methodDefinitionsFor_.st A Ring-Core-Kernel.package/RGBehaviorDefinition.class/instance/annotations/hasDefinitionSource.st M Ring-Monticello.package/extension/RGMethodDefinition/instance/asMCMethodDefinition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50092.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50093.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50092.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50093.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-ExternalBrowser.package/CurrentImage.class/README.md A Tool-ExternalBrowser.package/CurrentImage.class/definition.st A Tool-ExternalBrowser.package/CurrentImage.class/instance/accessing/packages.st A Tool-ExternalBrowser.package/ExternalBrowser.class/README.md A Tool-ExternalBrowser.package/ExternalBrowser.class/class/System-FileRegistry/fileReaderServicesForFile_suffix_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/class/System-FileRegistry/serviceBrowseCode.st A Tool-ExternalBrowser.package/ExternalBrowser.class/class/System-FileRegistry/services.st A Tool-ExternalBrowser.package/ExternalBrowser.class/class/class initialization/initialize.st A Tool-ExternalBrowser.package/ExternalBrowser.class/class/public access/browseStream_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/class/specs/defaultSpec.st A Tool-ExternalBrowser.package/ExternalBrowser.class/class/specs/openOn_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/definition.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/classes.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/method.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/method_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/model_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/packages.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/protocols.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/selectors.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/selectors_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/showClassSide.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/accessing/title.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initialExtent.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializeClassList.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializeMethodBodyPane.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializePackageList.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializePresenter.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializeProtocolList.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializeSelectorList.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/initializeWidgets.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/refreshClasses_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/wireClasses.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/wirePackages.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/wireProtocols.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/initialize/wireSelectors.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/selection operation/populatePackages.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/selection operation/resetClassSelection.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/selection operation/resetMethodBodyPane.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/selection operation/resetProtocolSelection.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/selection operation/resetSelectorSelection.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/classesOfPackage_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/methodFor_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/protocolsOfClass_.st A Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/selectorsOfProtocol_.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/README.md A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/class/instance creation/openOn_.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/class/specs/defaultSpec.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/definition.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/acccessing/changes.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/acccessing/codePane.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/acccessing/deselectAllButton.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/acccessing/fileInSelectedButton.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/acccessing/selectAllButton.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/initialization/changeDescription_.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/initialization/changeSetName_.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/initialization/initialExtent.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/initialization/initializePresenter.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/initialization/initializeWidgets.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/menu/buildMenu_.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/menu/canCompareToCurrent.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/menu/compareToCurrent_.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/instance/menu/fileIn_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/README.md A Tool-ExternalBrowser.package/RingChunkImporter.class/class/instance creation/fromFileNamed_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/class/instance creation/fromStream_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/definition.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/accessing/classes.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/accessing/doIts.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/accessing/packages.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/initialize/initialize.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/classDefinition_with_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/classNamed_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/createClassNamed_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/createTraitNamed_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/metaClassDefinition_with_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/metaTraitDefinition_with_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/msgClassComment_with_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/removedMethod_with_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/scannedSource_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/traitDefinition_with_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/reading/fileInFrom_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/reading/fromFileNamed_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/visitor/visitClassCommentChunk_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/visitor/visitClassOrganizationChunk_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/visitor/visitDoItChunk_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/visitor/visitMethodChunk_.st A Tool-ExternalBrowser.package/RingChunkImporter.class/instance/visitor/visitStyleChunk_.st Log Message: ----------- 50093 15658 Prepare FilePackageRemoval and FileContentsBrowser https://pharo.fogbugz.com/f/cases/15658 http://files.pharo.org/image/50/50093.zip

June 6, 2015

Re: [Pharo-dev] [squeak-dev] Is this a bug with Step "Over"?

by Ben Coman

On Sat, Jun 6, 2015 at 4:35 AM, Chris Muller <asqueaker(a)gmail.com> wrote: > 3 timesRepeat: [Warning signal]. > 10 factorial > > Select the above in a workspace, select "debug it" then, in the > debugger, click the "Over" button just once. > > 3 Warning pre-debuggers appear instantly and then the execution moves > to the "factorial". > > Warnings have the opportunity to resume or cancel? IOW, shouldn't it > work more like as if it were a halt? > > 3 timesRepeat: [ self halt ]. > 10 factorial > Pharo does the same and its an interesting question so I've cross posted. If you "do it" then you get *one* pre-debug window at a time. When you "debug it" and step "Over" you get *three* debug windows at once. Shouldn't it behave the same as the "do it" to get *one* at a time ? cheers -ben

June 6, 2015

Re: [Pharo-dev] Roassal Camp Smalltalk

by Peter UhnÃ¡k

Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. Peter On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât > updated for a long time. Maybe I was wrong. > > Uko > > > > On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > There sure are, look at ConfigurationOfRoassal2>>version*: > > and in my baseline I have something like > > ~~~~~~~~~~~ > spec > project: 'Roassal2' with: [ > spec > className: #ConfigurationOfRoassal2; > versionString: '1.52'; > repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; > ~~~~~~~~~~~ > > Peter > > On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> But are there numbered version to refer to? >> >> Uko >> >> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> >> >> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>> Iâm interested in participating. Personally Iâd like to talk more about >>> design decisions behind roassal ecosystem, release strategy and so on. >>> Usually when I work with Roassal I have this issue that things are breaking >>> because of rapid changes, or because of the differences between different >>> parts of roassal. Maybe someone is also concerned about this, so we can >>> discuss and maybe improve somethingâ¦ >>> >> >> Yes I am also interested in this, right now I am actually using quite old >> version (month+) because I didn't have time to keep up. :) (Arguably 90% of >> my problems were from infamous composite shapes. :)) >> >> Peter >> >>> >>> Uko >>> >>> > On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com> >>> wrote: >>> > >>> > Dear Colleagues and Friends, >>> > >>> > We are happy to announce we will organize a CampSmalltalk about the >>> Roassal visualization engine, on _Sunday 12 July_. >>> > >>> > As far as we have seen, the interests are multiple. Here is a list of >>> topics we will happy to work on: >>> > - Port of Roassal on VisualWorks >>> > - Using Roassal on Gemstone >>> > - HTML/JavaScript export >>> > - Improving Grapher, our charting library >>> > >>> > If you wish to participate, get in touch with us. Since we will >>> probably have a sponsoring of the event, it would be nice to know how many >>> will attend to ease the logistic and the pizza ordering :-) >>> > >>> > Cheers, >>> > Alexandre >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> >>> >>> >> >> > >

June 5, 2015

Re: [Pharo-dev] Refactoring File Package

by stepharo

Yes sven but with guille we are working on a really small kernel. So we can duplicate just the classes we need but I would prefer not but we can do it. The size is important for us because it takes time to bootstrap. Stef Le 5/6/15 19:06, Sven Van Caekenberghe a Ã©crit : >> On 05 Jun 2015, at 18:43, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> The only encoder that makes a bit of noise to me is the ZnByteEncoder that contains a lot of mapping tables for mostly unused encodings > 67 encoding specifications, each a 128 array. The method constant is shared when used. > In the beginning there were only a couple, one day I added many more, some people need them. > For me, the cost is reasonable. > >> (plus methods with metadata to recreate them)... > That is just two method (which is pretty cool, I love spec based programming). > >> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >> >>> On 05 Jun 2015, at 18:20, stepharo <stepharo(a)free.fr> wrote: >>> >>> Sven >>> >>> we were talking about splitting your package into two parts :) >>> Would you be ok to get the basic encoders in a separate package? >> Zinc-Character-Encoding is already a separate package, it depends on nothing. >> Zinc-Resource-Meta is next up (containing URL and Mime-Type). >> Both are completely independent of any HTTP stuff. >> All this is by design. >> >> You probably mean that you want a separate config ? Right now they are just a groups. >> >>> We were also thinking that NullEncoder could be called AsciiEncoder? >> Maybe, maybe not, let me think about that a bit. >> >>> Stef >>> >>>>> On 05 Jun 2015, at 18:09, Damien Cassou <damien.cassou(a)inria.fr> wrote: >>>>> >>>>> >>>>> Guillermo Polito <guillermopolito(a)gmail.com> writes: >>>>> >>>>>> Well, I made a cleaner implementation at the side with >>>>>> >>>>>> - a simple File object that is a sequential File as we all know >>>>>> - a binary File stream on top of it that is composable with Zn encoders and >>>>>> other decorators >>>>>> - a new interface to access Stdio streams >>>>> that's really good news Guillermo. >>>> Yes it is (need time to look at this in detail) >>>> >>>>> Is it ok to make File reading depend >>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping harder? >>>> It does not depend on the HTTP part, but on the Encoding part below it, so that should be OK. >>>> >>>>> -- >>>>> Damien Cassou >>>>> http://damiencassou.seasidehosting.st >>>>> >>>>> "Success is the ability to go from one failure to another without >>>>> losing enthusiasm." --Winston Churchill >>>>> >>>> >>> >> > >

June 5, 2015

Re: [Pharo-dev] Roassal Camp Smalltalk

by Yuriy Tymchuk

Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât updated for a long time. Maybe I was wrong. Uko > On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > There sure are, look at ConfigurationOfRoassal2>>version*: > > and in my baseline I have something like > > ~~~~~~~~~~~ > spec > project: 'Roassal2' with: [ > spec > className: #ConfigurationOfRoassal2; > versionString: '1.52'; > repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/ <http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/>' ]; > ~~~~~~~~~~~ > > Peter > > On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > But are there numbered version to refer to? > > Uko > >> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> >> >> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> Iâm interested in participating. Personally Iâd like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve somethingâ¦ >> >> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >> >> Peter >> >> Uko >> >> > On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> > >> > Dear Colleagues and Friends, >> > >> > We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >> > >> > As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >> > - Port of Roassal on VisualWorks >> > - Using Roassal on Gemstone >> > - HTML/JavaScript export >> > - Improving Grapher, our charting library >> > >> > If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >> > >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> > >

June 5, 2015

Re: [Pharo-dev] Refactoring File Package

by Sven Van Caekenberghe

> On 05 Jun 2015, at 18:43, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > The only encoder that makes a bit of noise to me is the ZnByteEncoder that contains a lot of mapping tables for mostly unused encodings 67 encoding specifications, each a 128 array. The method constant is shared when used. In the beginning there were only a couple, one day I added many more, some people need them. For me, the cost is reasonable. > (plus methods with metadata to recreate them)... That is just two method (which is pretty cool, I love spec based programming). > El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > > On 05 Jun 2015, at 18:20, stepharo <stepharo(a)free.fr> wrote: > > > > Sven > > > > we were talking about splitting your package into two parts :) > > Would you be ok to get the basic encoders in a separate package? > > Zinc-Character-Encoding is already a separate package, it depends on nothing. > Zinc-Resource-Meta is next up (containing URL and Mime-Type). > Both are completely independent of any HTTP stuff. > All this is by design. > > You probably mean that you want a separate config ? Right now they are just a groups. > > > We were also thinking that NullEncoder could be called AsciiEncoder? > > Maybe, maybe not, let me think about that a bit. > > > Stef > > > >>> On 05 Jun 2015, at 18:09, Damien Cassou <damien.cassou(a)inria.fr> wrote: > >>> > >>> > >>> Guillermo Polito <guillermopolito(a)gmail.com> writes: > >>> > >>>> Well, I made a cleaner implementation at the side with > >>>> > >>>> - a simple File object that is a sequential File as we all know > >>>> - a binary File stream on top of it that is composable with Zn encoders and > >>>> other decorators > >>>> - a new interface to access Stdio streams > >>> that's really good news Guillermo. > >> Yes it is (need time to look at this in detail) > >> > >>> Is it ok to make File reading depend > >>> on Zinc? This sounds strange. Wouldn't that make bootstrapping harder? > >> It does not depend on the HTTP part, but on the Encoding part below it, so that should be OK. > >> > >>> -- > >>> Damien Cassou > >>> http://damiencassou.seasidehosting.st > >>> > >>> "Success is the ability to go from one failure to another without > >>> losing enthusiasm." --Winston Churchill > >>> > >> > >> > > > > > >

June 5, 2015