December 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 7 changelog proposal

by phil＠highoctane.be

Cool. Calypso and multiple tags per method is not really functional at this point. Phil On Sun, Dec 23, 2018, 12:29 Pavel Krivanek <pavel.krivanek(a)gmail.com wrote: > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 > merged PRs, not counting standalone commits to Iceberg and Calypso). If > something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests >

Dec. 23, 2018

Re: [Pharo-dev] stfx.eu down

by phil＠highoctane.be

Yes, very welcome!! Phil On Sun, Dec 23, 2018, 09:59 Stephane Ducasse <stepharo.self(a)gmail.com wrote: > Thanks Sven!!! > > On Sat, Dec 22, 2018 at 8:13 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > > > > On 11 Dec 2018, at 21:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> > > >> Hi, > > >> > > >> This evening I somehow broke my stfx.eu server while doing an ubuntu > dist upgrade (an old AWS EC2 machine). > > >> > > >> This means several websites / web services hosted by that machine are > down, most notably mc.stfx.eu (hosting several of my packages) and > ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests > will also fail. > > > > > > I recovered parts of the functionality: ws.stfx.eu (shared smalltalk > workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests > should pass everywhere. > > > > > > At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 > 64-bit, as it should. > > > > > > Next up is http://mc.stfx.eu for my Monticello repository, but that > might take more time. > > > > At last, http://mc.stfx.eu is back up. > > > > I still recommend everyone to use the http://github.com/svenvc versions > of my projects, as this is the better option going forward. I also intend > to use these as primary repositories. > > > > >> For source code access, all my public repos exist both in an up to > date form on GitHub (http://github.com/svenvc) as well in the original > form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or > SS3. > > >> > > >> The main problem there is that the distributed ConfigurationsOf and > Catalog entries will still point to the original. This is not a problem > with git's BaselineOf definitions. > > >> > > >> Although the machine will no longer boot, I managed to mount the > original volume on another instance so I can still access the whole > filesystem. This will make it possible to eventually recover most services. > But this will take time as these things never happen when it is convenient. > It will give me an opportunity to modernise the setup though, which is good. > > >> > > >> Sorry for the inconvenience. > > >> > > >> Sven > > >> > > > > > > > > >

Dec. 23, 2018

Re: [Pharo-dev] stfx.eu down

by Stephane Ducasse

Thanks Sven!!! On Sat, Dec 22, 2018 at 8:13 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 11 Dec 2018, at 21:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Hi, > >> > >> This evening I somehow broke my stfx.eu server while doing an ubuntu dist upgrade (an old AWS EC2 machine). > >> > >> This means several websites / web services hosted by that machine are down, most notably mc.stfx.eu (hosting several of my packages) and ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests will also fail. > > > > I recovered parts of the functionality: ws.stfx.eu (shared smalltalk workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests should pass everywhere. > > > > At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 64-bit, as it should. > > > > Next up is http://mc.stfx.eu for my Monticello repository, but that might take more time. > > At last, http://mc.stfx.eu is back up. > > I still recommend everyone to use the http://github.com/svenvc versions of my projects, as this is the better option going forward. I also intend to use these as primary repositories. > > >> For source code access, all my public repos exist both in an up to date form on GitHub (http://github.com/svenvc) as well in the original form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or SS3. > >> > >> The main problem there is that the distributed ConfigurationsOf and Catalog entries will still point to the original. This is not a problem with git's BaselineOf definitions. > >> > >> Although the machine will no longer boot, I managed to mount the original volume on another instance so I can still access the whole filesystem. This will make it possible to eventually recover most services. But this will take time as these things never happen when it is convenient. It will give me an opportunity to modernise the setup though, which is good. > >> > >> Sorry for the inconvenience. > >> > >> Sven > >> > > > >

Dec. 23, 2018

Pharo 7 changelog proposal

by Pavel Krivanek

Hi, I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged PRs, not counting standalone commits to Iceberg and Calypso). If something more should be mentioned, please let me know. Revolutionary kernel changes - bootstrap - modular stateful traits - traits flattening in kernel packages - new sources file for every bootstrapped version, empty changes - new class builder - binary packages loading (Hermes) Infrastructure changes - switch to GitHub - Tonel code format - update building infrastructure to Jenkins 2 Code management - Calypso, the new system browser - new navigation model - faster UI - tabs toolbar instead of single source code panel - explicit commands instead of duplicated menu and shortcuts - extendable by plugins - suitable for the remote scenario - "dynamic protocols", support multiple tags per method - not required star convention for class extension - support multiple tags per class - visibility option for inherited methods - methods inherited from traits are not shown by default - variable view as the special mode for method group view. - better keyboard navigation - and many more Iceberg - a new friendly user interface - simplification of solving problems with repositories - workflow simplification - better GitHub, BitBucket, GitLab support - improved code merging and comparisons - new code serialization format (Tonel) - repositories metadata - documentation - better error handling, tags support - improved Iceberg-Metacello integration - credentials store Cleanups - remove Nautilus - remove UpdateStream - remove all Configurations - remove ShoreLine-Report - remove TxText - remove PluggableTabBarMorph - remove the old Compiler - remove Watery theme - remove Versionner - remove Komitter - remove LegacyWeakSubscription - continue on deprecation of FileStream - dead code cleanups - code organization cleanups - unify categorization of common methods - cleanups of object inspection protocol - start with Ring deprecation - better structure of packages - package comments Updates - Zinc - Epicea - FFI - Metacello - Fuel New - Calypso - integrate WebBrowser - integrate ReferenceFinder - Hermes - Refactoring 2 - Commander - ClassAnnotation Spec - ComposableModel renamed to ComposablePresenter - new calendar presenter - Spec-Demo - improve Spec linking to domain models Look & Feel - use the white theme by default - improve themes switching - main menu bar - new window management shortcuts - better support of fallback bitmap fonts - improved Inspector refreshing - Spotter is looking for opened windows - display scale factor - FastTable improvements VM interface - DoubleWord and DoubleByte arrays - add EncoderForSistaV1 - read-only literals support - improvements and fixes for 64-bit support - fixes for FullBlockClosure - support of the new bytecode set Reflectivity - breakpoints improvements - test coverage using metalinks - reflectivity and metalinks improvements Other - startup running in a fresh process - better pin messages - NewValueHolder and Model API unification - better working and image directories meaning separation - SortFunctions composable - better OSWindow support - convert rules to the Renraku architecture - class and method comments improvements - extensible Playground (pageActionOrder:) - optional password management for command line handlers - system dependencies tests - unify way to obtain package manifests

Dec. 23, 2018

Re: [Pharo-dev] stfx.eu down

by Sven Van Caekenberghe

> On 11 Dec 2018, at 21:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> This evening I somehow broke my stfx.eu server while doing an ubuntu dist upgrade (an old AWS EC2 machine). >> >> This means several websites / web services hosted by that machine are down, most notably mc.stfx.eu (hosting several of my packages) and ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests will also fail. > > I recovered parts of the functionality: ws.stfx.eu (shared smalltalk workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests should pass everywhere. > > At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 64-bit, as it should. > > Next up is http://mc.stfx.eu for my Monticello repository, but that might take more time. At last, http://mc.stfx.eu is back up. I still recommend everyone to use the http://github.com/svenvc versions of my projects, as this is the better option going forward. I also intend to use these as primary repositories. >> For source code access, all my public repos exist both in an up to date form on GitHub (http://github.com/svenvc) as well in the original form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or SS3. >> >> The main problem there is that the distributed ConfigurationsOf and Catalog entries will still point to the original. This is not a problem with git's BaselineOf definitions. >> >> Although the machine will no longer boot, I managed to mount the original volume on another instance so I can still access the whole filesystem. This will make it possible to eventually recover most services. But this will take time as these things never happen when it is convenient. It will give me an opportunity to modernise the setup though, which is good. >> >> Sorry for the inconvenience. >> >> Sven >> >

Dec. 22, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Ben Coman

On Sat, 22 Dec 2018 at 06:03, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: > > First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. Was this on Windows? What was the fix for worked for you? (sorry its easier to ask again than try to identify in the archives a previous mention) cheers -ben > It was related with some mozilla library for font redering that didn't work well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. > > I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. > > This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. > > In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. > > Cheers, > > Offray > > On 21/12/18 10:59, Luke Gorrie wrote: > > On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. > > [...] >> >> Does this address the concern? > > > I am not sure yet :). > > Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. > > In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. > > The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. > > I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. > > Hints would be appreciated :) > > I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. > > Cheers! > -Luke > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi Offray, Thanks for describing your concerns. First, letâs address the technical part. Please go to gtoolkit.com and download the 64Bit distribution that includes the image and the VM. We will remove the standalone image option from the website until the VM situation gets clarified. Now, a clarification. The old GT was produced over a period of 4 years by an open-source team. The project had its own identity, and in 2014 the core of it was first integrated in Pharo. I say the core of it, because the visual part and other libraries are not in Pharo today. The full potential is found in Moose. In any case, during this process, GT got to be identified with Pharo and that was a good thing. The new GT is a product produced by feenk, a company. Much of the original team is still active in the new version, but now we commit to our product in a different way. The product is free and open-source, but itâs still a product with an identity and a goal. At present time, both the team, identity and goal are different than those of Pharo. Our goal is to offer a fundamentally new alternative to program (including comparing to what is possible now in Pharo). We are not looking for marginal improvements, and we are not aiming at backward compatibility. To build this alternative we invested in a whole new stack. That is not a tiny challenge and getting it right requires many iterations and feedback. We say we are in alpha not because of inconveniences of installation but because we are still very much developing the product. We announced the first alpha version in September and since then much has changed. At present time, we did manage to reach a situation where downloading the distribution should run on Mac, Linux and Windows. Even so, the current version is only for people that do want to try knowing that there will be hurdles. A word about the user experience. The current version runs inside the Pharo UI because we need to bootstrap. But, our goal is to build a complete IDE on the new stack. If you want to judge the user experience, it is only meaningful to do it within the GT windows, and not by comparing it with the rest of the existing Pharo UI. Does this clarify the situation? Cheers, Doru -- www.feenk.com "Every thing has its own flow." > On 21 Dec 2018, at 23:02, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: > > First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. It was related with some mozilla library for font redering that didn't work well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. > I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. > This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. > > In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. > > Cheers, > > Offray >> On 21/12/18 10:59, Luke Gorrie wrote: >> On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. >> [...] >>> Does this address the concern? >> >> I am not sure yet :). >> >> Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. >> >> In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. >> >> The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. >> >> I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. >> >> Hints would be appreciated :) >> >> I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. >> >> Cheers! >> -Luke >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-dev] How can I wrap a byteArray into a stream

by Stephane Ducasse

I found it :) initializeWithByteArray: aByteArrayStream | A B C D | in := ZnBufferedReadStream on: aByteArrayStream. "Read the end-of-data value" A := in next bitAnd: 16rFF. B := (in next bitAnd: 16rff) << 8. C := (in next bitAnd: 16rff) << 16. D := (in next bitAnd: 16rff) << 24. eod := A bitOr: (B bitOr: (C bitOr: D)). "Skip the rest of the hashtable" in skip: 2048 - 4. "Current data pointer" pos := 2048 On Fri, Dec 21, 2018 at 10:44 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Of course this is not next but int16 :) > > > I will look further into > > testInt16Aliases > | input writer | > writer := [ :block | > ByteArray streamContents: [ :out | > ZnBufferedWriteStream on: out do: block ] ]. > input := ByteArray readHexFrom: '04D2'. > self assert: (ZnBufferedReadStream on: input readStream) int16 equals: 1234. > self assert: (ZnBufferedReadStream on: input readStream) uint16 equals: 1234. > self assert: (ZnBufferedReadStream on: input readStream) nextWord equals: 1234. > self assert: ((ZnBufferedReadStream on: input readStream) nextNumber: > 2) equals: 1234. > self assert: ((ZnBufferedReadStream on: input reversed readStream) > nextLittleEndianNumber: 2) equals: 1234. > self assert: (writer value: [ :out | out int16: 1234 ]) equals: input. > self assert: (writer value: [ :out | out uint16: 1234 ]) equals: input. > self assert: (writer value: [ :out | out nextWordPut: 1234 ]) equals: input. > self assert: (writer value: [ :out | out nextNumber: 2 put: 1234 ]) > equals: input. > self assert: (writer value: [ :out | out nextLittleEndianNumber: 2 > put: 1234 ]) equals: input reversed. > input := ByteArray readHexFrom: 'FB2E'. > self assert: (ZnBufferedReadStream on: input readStream) int16 equals: -1234. > self assert: (writer value: [ :out | out int16: -1234 ]) equals: input > > > > > > On Fri, Dec 21, 2018 at 10:40 PM Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > > > Hi > > > > I'm fighting with super badly written code and my first reaction is a > > to be able to write tests and parametrize the code. > > > > I have some byteArray (contents of a CDB database) that I would like > > to manipulate using stream API. > > I'm looking for something like this > > > > ZnBinaryStream on: aByteArray; > > next; next; skip: 10; ... > > > > Stef

Dec. 21, 2018

Re: [Pharo-dev] How can I wrap a byteArray into a stream

by Stephane Ducasse

Of course this is not next but int16 :) I will look further into testInt16Aliases | input writer | writer := [ :block | ByteArray streamContents: [ :out | ZnBufferedWriteStream on: out do: block ] ]. input := ByteArray readHexFrom: '04D2'. self assert: (ZnBufferedReadStream on: input readStream) int16 equals: 1234. self assert: (ZnBufferedReadStream on: input readStream) uint16 equals: 1234. self assert: (ZnBufferedReadStream on: input readStream) nextWord equals: 1234. self assert: ((ZnBufferedReadStream on: input readStream) nextNumber: 2) equals: 1234. self assert: ((ZnBufferedReadStream on: input reversed readStream) nextLittleEndianNumber: 2) equals: 1234. self assert: (writer value: [ :out | out int16: 1234 ]) equals: input. self assert: (writer value: [ :out | out uint16: 1234 ]) equals: input. self assert: (writer value: [ :out | out nextWordPut: 1234 ]) equals: input. self assert: (writer value: [ :out | out nextNumber: 2 put: 1234 ]) equals: input. self assert: (writer value: [ :out | out nextLittleEndianNumber: 2 put: 1234 ]) equals: input reversed. input := ByteArray readHexFrom: 'FB2E'. self assert: (ZnBufferedReadStream on: input readStream) int16 equals: -1234. self assert: (writer value: [ :out | out int16: -1234 ]) equals: input On Fri, Dec 21, 2018 at 10:40 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I'm fighting with super badly written code and my first reaction is a > to be able to write tests and parametrize the code. > > I have some byteArray (contents of a CDB database) that I would like > to manipulate using stream API. > I'm looking for something like this > > ZnBinaryStream on: aByteArray; > next; next; skip: 10; ... > > Stef

Dec. 21, 2018

How can I wrap a byteArray into a stream

by Stephane Ducasse

Hi I'm fighting with super badly written code and my first reaction is a to be able to write tests and parametrize the code. I have some byteArray (contents of a CDB database) that I would like to manipulate using stream API. I'm looking for something like this ZnBinaryStream on: aByteArray; next; next; skip: 10; ... Stef

Dec. 21, 2018