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

Re: [Pharo-dev] [Vm-dev] Cog Rump Xen unikernel

by Eliot Miranda

Ben, great to hear you're working on this! I'm watching with bated breath! BTW, you might find that Docker is easier and more general; I believe there's no Xen for ARM for example, and ARM is increasingly interesting with up coming extremely cheap 64-bit versions of Pi and PINE. Good luck!! On Fri, Dec 11, 2015 at 10:27 AM, Ben Coman <btc(a)openinworld.com> wrote: > > I got curious about following up these two threads making Cog a > unikernel... > > Cog in the cloud > http://forum.world.st/Cog-in-the-cloud-td4796514.html > > Hosting the Pharo VM on MirageOS > http://forum.world.st/Hosting-the-Pharo-VM-on-MirageOS-td4799424.html#none > > > One path forward is to use rumpkernel, which "provides a means to run > existing POSIX applications as unikernels on Xen" > > https://blog.xenproject.org/2015/08/06/on-rump-kernels-and-the-rumprun-unik… > > Deploying real-world software today as unikernels on Xen with Rumprun > > http://events.linuxfoundation.org/sites/events/files/slides/xdps15-talk-fin… > > > So I thought I would try the "Building Rumprun Unikernels" tutorial here... > > https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikerne… > which I report here in case it was interest. The tutorial is based on > QEMU (and I think I saw a comment somewhere that Cog doesn't run so > well on QEMU and needs Bochs), so after that I adapted it from QEMU to > Xen. > > > 64-BIT DEBIAN 8 JESSIE & XEN > > So first I installed Debian 8 Jessie 64-bit on my new laptop > $ uname -a > >> ...x86_64 > > Then installed Xen and after a reboot could choose it from the boot menu. > $ apt-get update > $ apt get install xen-system-amd64 libxen-dev > > REBOOTED > > Tested manual selection from menu to boot into Xen dom0. > Checked Xen was operating with... > $ xl info > > > 32-BIT DEBIAN 8 JESSIE & XEN > > However later I hit some complications determining whether the rump > unikernel was being compiled 32-bit or 64-bit in order to mix in with > 32-bit Pharo, so to simplify things I did a complete reinstall of my > system as 32-bit. > $ uname -a > >> ...686-pae > > Then installed Xen again Xen only has a 64-bit hypervisor, but this > was not immediately available under 32-bit OS. I can't exactly > remember but I think I just needed to add multiarch before it would > find the Xen package. > $ apt-get update > $ apt-get install multiarch > $ apt get install xen-system-amd64 libxen-dev > Otherwise it may have needed something like "dpkg --add-architecture ..." > > REBOOTED > > First test, manually selected to boot into Xen dom0, after which as > root the following checked Xen was operating... > $ xl info > > Then set it to automatically boot into Xen... > $ dpkg-divert --divert /etc/grub.d/08_linux_xen --rename > /etc/grub.d/20_linux_xen > $ update-grub > REBOOTED > > > ==================================== > DID THE QUICK START TUTORIAL > USING GENERIC HW ON QEMU > > 0. Installed support tools and libs > > $ apt-get install build-essential git-core cmake > > 1. Built the rumprun platform > > $ mkdir -p ~/Repos/rumprun-hw > $ cd ~/Repos/rumprun-hw > $ git clone http://repo.rumpkernel.org/rumprun > $ cd rumprun > $ git submodule update --init > $ CC=cc ./build-rr.sh hw > Took note of this output needed later... > >> toolchain tuple: i486-rumprun-netbsdelf > >> cc wrapper: i486-rumprun-netbsdelf-gcc > > $ echo $(pwd) > /Users/ben/Repos/rumpkernel-hw/rumprun > $ export PATH="${PATH}:$(pwd)/rumprun/bin" > > > 2. Built a toy application > > $ mkdir -p test > $ cd test > $ cat > helloer.c << EOF .... > $ cc -o helloer helloer.c > $ i486-rumprun-netbsdelf-gcc -o helloer-rumprun helloer.c > $ rumprun-bake hw_generic helloer-rumprun.bin helloer-rumprun > > > 3. Ran the toy application > > $ su > > $ rumprun qemu -i helloer-rumprun.bin > > In another terminal, check its running > $ xl list > >> Name ID Mem ...etc > >> Domain-0 0 7583 > >> rumprun-hellor-rumprun.bin 1 64 > > The app takes over the terminal its run from, so from another terminal... > $ xl destroy rumprun-hellor-rumprun.bin > > > ==================================== > ADAPTED THE QUICK START TUTORIAL > FOR XEN PARAVIRTUALIZATION > > 0. Started a new terminal to get an environment with a clean PATH > > 1. Built the rumprun platform > > $ mkdir -p ~/Repos/rumprun-xen > $ cd ~/Repos/rumprun-xen > $ git clone http://repo.rumpkernel.org/rumprun > $ cd rumprun > $ git submodule update --init > $ CC=cc ./build-rr.sh xen #<<<< > Took note of this output needed later... > >> toolchain tuple: i486-rumprun-netbsdelf > >> cc wrapper: i486-rumprun-netbsdelf-gcc > > $ echo $(pwd) > /Users/ben/Repos/rumpkernel-xen/rumprun > $ export PATH="${PATH}:$(pwd)/rumprun/bin" > > > 2. Built a toy application > > $ mkdir -p test > $ cd test > $ cat > helloer.c << EOF .... > $ cc -o helloer helloer.c > $ i486-rumprun-netbsdelf-gcc -o helloer-rumprun helloer.c > $ rumprun-bake xen_pv helloer-rumprun.bin helloer-rumprun > > > 3. Ran toy application > > $ cd .. > $ su > $ export PATH="${PATH}:`pwd`/rumprun/bin > $ cd test > $ rumprun xen -i helloer-rumprun.bin > $ xl list > >> Name ID Mem ...etc > >> Domain-0 0 7583 > >> rumprun-hellor-rumprun.bin 1 64 > > This took over that terminal, so from another terminal... > $ xl destroy rumprun-hellor-rumprun.bin > > > ==================================== > TRIED IT USING CMAKE > > $ cat > CMakeLists.txt << EOF see this link for text... > > https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikerne… > > $ mkdir host_bld > $ cd host_bld > $ cmake -G "Unix Makefiles" .. > $ make > $ ./helloer > > $ cd .. > $ mkdir rumprun_bld > $ cd rumprun_bld > > Now with the given cmake line I got an error message: > Could not find toolchain file: > ../../rumprun/rumprun/share/x86_64-rumprun-netbsd-toolchain.cmake > > $ find ../.. -name x86_64-rumprun-netbsd-toolchain.cmake > found it, so that the following worked... > > $ cmake -G "Unix Makefiles" > > -DCMAKE_TOOLCHAIN_FILE=../../rumprun/rumprun-x86_64/share/x86_64-rumprun-netbsd-toolchain.cmake > .. > $ make > $ rumprun-bake xen_pv helloer.bin helloer > $ rumprun-bake hw_generic helloer.bin helloer > $ rumprun xen -i helloer.bin > > Next I'll report on initial steps to get Cog working on Xen as a Rump > unikernel... > > cheers -ben > -- _,,,^..^,,,_ best, Eliot

Dec. 11, 2015

Re: [Pharo-dev] Some GT tool for this?

by Mariano Martinez Peck

On Fri, Dec 11, 2015 at 12:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Mariano, > > for this in Squeak I added a simple menu pick to the Monticello > Browser's package list menu called "search history" which opens up a > workspace containing the entire history as a flat string. I then just > search using ctrl-f. You can find it in a current squeak trunk image. > > Hi Eliot, Yes, I was thinking the same. In the meanwhile, I did this extension: MCWorkingCopy >> gtInspectorIrIn: composite <gtInspectorPresentationOrder: 30> composite text title: 'History'; display: [ :workingCopy | TimeProfiler spyOn: [| stream versionInfos | stream := String new writeStream. versionInfos := workingCopy ancestry withBreadthFirstAncestors select: [:each | each isKindOf: MCVersionInfo]. versionInfos do: [ :each | stream nextPutAll: each summary; cr; cr. ]. stream contents.]. ] And then I can use the regular cmd+f to search the string. But I have to manually inspect the package doing something like: (MCWorkingCopy allManagers detect: [:each | each packageName = 'MyPackage']) inspect. > _,,,^..^,,,_ (phone) > > On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > How many times have you tried to search a string as a comment of a commit > in all the history? Myself: many many times. I know we need much better > tools for that, store the history in a another way, provide a nicer API, > etc etc. And I know there were topics about that. > > However, I would deeply appreciate a very short term solution for ease > that. The model side is as simple as this: > > | packageName ancestry anscestors substring | > packageName := 'MyPackageXX'. > substring := 'whatever I want to search'. > ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = > packageName] ) ancestry. > anscestors := ancestry withBreadthFirstAncestors select: [:each | each > isKindOf: MCVersionInfo]. > anscestors select: [ :each | each message includesSubstring: substring ] > > Do you think it's worth a simple UI tool? Custom inspector of MCAncestry? > > Cheers, > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 11, 2015

Re: [Pharo-dev] Some GT tool for this?

by Andrei Chis

You can add the two methods below. Then when you open Spotter on a package you can also search through it's history. This will trigger an update if the history is not present, but Spotter will still respond quite fast. You can also dive in a MCVersionInfo to see its ancestors. RPackage>>spotterHistoryFor: aStep <spotterOrder: 100> aStep listProcessor title: 'History'; allCandidates: [ |ancestry| ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = self name]) ancestry. ancestry withBreadthFirstAncestors select: [:each | each isKindOf: MCVersionInfo] ]; candidatesLimit: 50; itemName: [ :each | each name, ' - ', each message ]; filter: GTFilterSubstrings MCVersionInfo>>spotterPreviewCodeIn: aComposite <spotterPreview: 10> aComposite text title: 'Summary'; display: [ self summaryHeader, String cr, 'Message:', String cr, self message ]; entity: self. Cheers, Andrei On Fri, Dec 11, 2015 at 4:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Mariano, > > for this in Squeak I added a simple menu pick to the Monticello > Browser's package list menu called "search history" which opens up a > workspace containing the entire history as a flat string. I then just > search using ctrl-f. You can find it in a current squeak trunk image. > > _,,,^..^,,,_ (phone) > > On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > How many times have you tried to search a string as a comment of a commit > in all the history? Myself: many many times. I know we need much better > tools for that, store the history in a another way, provide a nicer API, > etc etc. And I know there were topics about that. > > However, I would deeply appreciate a very short term solution for ease > that. The model side is as simple as this: > > | packageName ancestry anscestors substring | > packageName := 'MyPackageXX'. > substring := 'whatever I want to search'. > ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = > packageName] ) ancestry. > anscestors := ancestry withBreadthFirstAncestors select: [:each | each > isKindOf: MCVersionInfo]. > anscestors select: [ :each | each message includesSubstring: substring ] > > Do you think it's worth a simple UI tool? Custom inspector of MCAncestry? > > Cheers, > > > -- > Mariano > http://marianopeck.wordpress.com > >

Dec. 11, 2015

Cog Rump Xen unikernel

by Ben Coman

I got curious about following up these two threads making Cog a unikernel... Cog in the cloud http://forum.world.st/Cog-in-the-cloud-td4796514.html Hosting the Pharo VM on MirageOS http://forum.world.st/Hosting-the-Pharo-VM-on-MirageOS-td4799424.html#none One path forward is to use rumpkernel, which "provides a means to run existing POSIX applications as unikernels on Xen" https://blog.xenproject.org/2015/08/06/on-rump-kernels-and-the-rumprun-unik… Deploying real-world software today as unikernels on Xen with Rumprun http://events.linuxfoundation.org/sites/events/files/slides/xdps15-talk-fin… So I thought I would try the "Building Rumprun Unikernels" tutorial here... https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikerne… which I report here in case it was interest. The tutorial is based on QEMU (and I think I saw a comment somewhere that Cog doesn't run so well on QEMU and needs Bochs), so after that I adapted it from QEMU to Xen. 64-BIT DEBIAN 8 JESSIE & XEN So first I installed Debian 8 Jessie 64-bit on my new laptop $ uname -a >> ...x86_64 Then installed Xen and after a reboot could choose it from the boot menu. $ apt-get update $ apt get install xen-system-amd64 libxen-dev REBOOTED Tested manual selection from menu to boot into Xen dom0. Checked Xen was operating with... $ xl info 32-BIT DEBIAN 8 JESSIE & XEN However later I hit some complications determining whether the rump unikernel was being compiled 32-bit or 64-bit in order to mix in with 32-bit Pharo, so to simplify things I did a complete reinstall of my system as 32-bit. $ uname -a >> ...686-pae Then installed Xen again Xen only has a 64-bit hypervisor, but this was not immediately available under 32-bit OS. I can't exactly remember but I think I just needed to add multiarch before it would find the Xen package. $ apt-get update $ apt-get install multiarch $ apt get install xen-system-amd64 libxen-dev Otherwise it may have needed something like "dpkg --add-architecture ..." REBOOTED First test, manually selected to boot into Xen dom0, after which as root the following checked Xen was operating... $ xl info Then set it to automatically boot into Xen... $ dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen $ update-grub REBOOTED ==================================== DID THE QUICK START TUTORIAL USING GENERIC HW ON QEMU 0. Installed support tools and libs $ apt-get install build-essential git-core cmake 1. Built the rumprun platform $ mkdir -p ~/Repos/rumprun-hw $ cd ~/Repos/rumprun-hw $ git clone http://repo.rumpkernel.org/rumprun $ cd rumprun $ git submodule update --init $ CC=cc ./build-rr.sh hw Took note of this output needed later... >> toolchain tuple: i486-rumprun-netbsdelf >> cc wrapper: i486-rumprun-netbsdelf-gcc $ echo $(pwd) /Users/ben/Repos/rumpkernel-hw/rumprun $ export PATH="${PATH}:$(pwd)/rumprun/bin" 2. Built a toy application $ mkdir -p test $ cd test $ cat > helloer.c << EOF .... $ cc -o helloer helloer.c $ i486-rumprun-netbsdelf-gcc -o helloer-rumprun helloer.c $ rumprun-bake hw_generic helloer-rumprun.bin helloer-rumprun 3. Ran the toy application $ su $ rumprun qemu -i helloer-rumprun.bin In another terminal, check its running $ xl list >> Name ID Mem ...etc >> Domain-0 0 7583 >> rumprun-hellor-rumprun.bin 1 64 The app takes over the terminal its run from, so from another terminal... $ xl destroy rumprun-hellor-rumprun.bin ==================================== ADAPTED THE QUICK START TUTORIAL FOR XEN PARAVIRTUALIZATION 0. Started a new terminal to get an environment with a clean PATH 1. Built the rumprun platform $ mkdir -p ~/Repos/rumprun-xen $ cd ~/Repos/rumprun-xen $ git clone http://repo.rumpkernel.org/rumprun $ cd rumprun $ git submodule update --init $ CC=cc ./build-rr.sh xen #<<<< Took note of this output needed later... >> toolchain tuple: i486-rumprun-netbsdelf >> cc wrapper: i486-rumprun-netbsdelf-gcc $ echo $(pwd) /Users/ben/Repos/rumpkernel-xen/rumprun $ export PATH="${PATH}:$(pwd)/rumprun/bin" 2. Built a toy application $ mkdir -p test $ cd test $ cat > helloer.c << EOF .... $ cc -o helloer helloer.c $ i486-rumprun-netbsdelf-gcc -o helloer-rumprun helloer.c $ rumprun-bake xen_pv helloer-rumprun.bin helloer-rumprun 3. Ran toy application $ cd .. $ su $ export PATH="${PATH}:`pwd`/rumprun/bin $ cd test $ rumprun xen -i helloer-rumprun.bin $ xl list >> Name ID Mem ...etc >> Domain-0 0 7583 >> rumprun-hellor-rumprun.bin 1 64 This took over that terminal, so from another terminal... $ xl destroy rumprun-hellor-rumprun.bin ==================================== TRIED IT USING CMAKE $ cat > CMakeLists.txt << EOF see this link for text... https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikerne… $ mkdir host_bld $ cd host_bld $ cmake -G "Unix Makefiles" .. $ make $ ./helloer $ cd .. $ mkdir rumprun_bld $ cd rumprun_bld Now with the given cmake line I got an error message: Could not find toolchain file: ../../rumprun/rumprun/share/x86_64-rumprun-netbsd-toolchain.cmake $ find ../.. -name x86_64-rumprun-netbsd-toolchain.cmake found it, so that the following worked... $ cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=../../rumprun/rumprun-x86_64/share/x86_64-rumprun-netbsd-toolchain.cmake .. $ make $ rumprun-bake xen_pv helloer.bin helloer $ rumprun-bake hw_generic helloer.bin helloer $ rumprun xen -i helloer.bin Next I'll report on initial steps to get Cog working on Xen as a Rump unikernel... cheers -ben

Dec. 11, 2015

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Dimitris Chloupis

easy to answer that .... initialize their values , make sure you use sensible names for the dictionary entries. documented and still no image pollution. On Fri, Dec 11, 2015 at 8:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 11 Dec 2015, at 17:45, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > the real question here is why pharo classes have the tendency to output > so much data through individual methods when a single method returning a > dictionary or any other collection would make much more sense and would be > far more flexible and elegant to deal with. Unnecessary pollution of the > image with methods. > > Hmm, I wouldn't call that pollution. I think it is a form of > documentation. The options are a good example of that. We could add an > accessor for #options, just returning the dictionary that is now > encapsulated, and then delete all the nice accessors, like > #useGzipCompressionAndChunking. With the accessors gone, how would you > discover or see what is available ? Where should the existing options be > documented ? Now you can browse them in the options protocol, all in one > place, one by one, with documentation and clearly visible defaults. > > > On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 11 Dec 2015, at 16:28, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > > > > > > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > Because there are many options, 10, 20, and at that time slots were > not yet available. > > > > > > Is not it is same case as class with 20 variables which always smell > bad? > > > > That's why it is a dictionary ;-) > > > > Can't an object have 10, 20 or more properties (independent of how they > are stored) ? > > > > You could of course delegate options to another sub object but why ? > > > > Apart from that, I do agree that both the main server object and the > main client object are too big, they are like big interfaces to a lot of > related functionality. The objects behind them, the ones in Zinc-HTTP-Core, > are much more single purpose and simpler. > > >

Dec. 11, 2015

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Sven Van Caekenberghe

> On 11 Dec 2015, at 17:45, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > the real question here is why pharo classes have the tendency to output so much data through individual methods when a single method returning a dictionary or any other collection would make much more sense and would be far more flexible and elegant to deal with. Unnecessary pollution of the image with methods. Hmm, I wouldn't call that pollution. I think it is a form of documentation. The options are a good example of that. We could add an accessor for #options, just returning the dictionary that is now encapsulated, and then delete all the nice accessors, like #useGzipCompressionAndChunking. With the accessors gone, how would you discover or see what is available ? Where should the existing options be documented ? Now you can browse them in the options protocol, all in one place, one by one, with documentation and clearly visible defaults. > On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 11 Dec 2015, at 16:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > > > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Because there are many options, 10, 20, and at that time slots were not yet available. > > > > Is not it is same case as class with 20 variables which always smell bad? > > That's why it is a dictionary ;-) > > Can't an object have 10, 20 or more properties (independent of how they are stored) ? > > You could of course delegate options to another sub object but why ? > > Apart from that, I do agree that both the main server object and the main client object are too big, they are like big interfaces to a lot of related functionality. The objects behind them, the ones in Zinc-HTTP-Core, are much more single purpose and simpler.

Dec. 11, 2015

[pharo-project/pharo-core] 950ae8: 50495

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 950ae8914e92c7b765a8e39656335c8140d8c938 https://github.com/pharo-project/pharo-core/commit/950ae8914e92c7b765a8e396… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-11 (Fri, 11 Dec 2015) Changed paths: M Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/debug and other/userString.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50494.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50495.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50494.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50495.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50495 17226 PluggableListMorph>>#userString should return one string https://pharo.fogbugz.com/f/cases/17226 http://files.pharo.org/image/50/50495.zip

Dec. 11, 2015

[pharo-project/pharo-core]

by GitHub

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

Dec. 11, 2015

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Dimitris Chloupis

the real question here is why pharo classes have the tendency to output so much data through individual methods when a single method returning a dictionary or any other collection would make much more sense and would be far more flexible and elegant to deal with. Unnecessary pollution of the image with methods. On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 11 Dec 2015, at 16:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > > > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Because there are many options, 10, 20, and at that time slots were not > yet available. > > > > Is not it is same case as class with 20 variables which always smell bad? > > That's why it is a dictionary ;-) > > Can't an object have 10, 20 or more properties (independent of how they > are stored) ? > > You could of course delegate options to another sub object but why ? > > Apart from that, I do agree that both the main server object and the main > client object are too big, they are like big interfaces to a lot of related > functionality. The objects behind them, the ones in Zinc-HTTP-Core, are > much more single purpose and simpler. >

Dec. 11, 2015

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Sven Van Caekenberghe

> On 11 Dec 2015, at 16:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Because there are many options, 10, 20, and at that time slots were not yet available. > > Is not it is same case as class with 20 variables which always smell bad? That's why it is a dictionary ;-) Can't an object have 10, 20 or more properties (independent of how they are stored) ? You could of course delegate options to another sub object but why ? Apart from that, I do agree that both the main server object and the main client object are too big, they are like big interfaces to a lot of related functionality. The objects behind them, the ones in Zinc-HTTP-Core, are much more single purpose and simpler.

Dec. 11, 2015