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

Re: [Pharo-dev] Smalltalk in a C World

by kilon alios

Pharo can already communicate natively with objective C and all its libraries via Nativeboost. An example is Mars on Pharo. http://marsonpharo.wordpress.com/ Nativeboost of course can communicate with C and it even offers an inline Assembler so you can go down to bare metal having all the speed and performance you want. Nativeboost cannot communicate with C++ currently , so it cant use C++ libraries like VTK , however there is a workaround. It is possible to wrap a C++ to a C DLL (or the equivelant of other OS) , thus indirectly Nativeboost can use even C++ libraries. Here is how -> http://stackoverflow.com/questions/199418/using-c-library-in-c-code Overall when dealing with C/C++ you have to deal with all sort of technically issues that you don't have in pharo. The problem also becomes even worse because C/C++ libraries usually are not made with simplicity in mind. In the case for example of CAD software with pharo this is of course doable but you will need to have a very deep understanding how 3d graphics works which is a highly technically area by itself. So as you can see there are loads of technically problems to overcome even before worrying about Pharo. But none the less its doable. On Sat, Dec 7, 2013 at 5:24 AM, askoh <askoh(a)askoh.com> wrote: > http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf > > The paper talks about Smalltalk and Objective C coexisting equally in a > software development environment. And by virtual of ObjC compatibility with > C/C++, the whole C world is open to Smalltalk. Isn't this very exciting? > Anyone else noticing this? Can Pragmatic Smalltalk be used to develop a CAD > system using the OpenCascade and Visualization Toolkit (VTK) open source > libraries? > > Can this work help us enter the Apple ecosystem? > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Smalltalk-in-a-C-World-tp4728217.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 7, 2013

[pharo-project/pharo-core]

by GitHub

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

Dec. 7, 2013

[pharo-project/pharo-core] 83e8a2: 30629

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 83e8a236eaaec97b899b6ae11a98cf39ce2c7695 https://github.com/pharo-project/pharo-core/commit/83e8a236eaaec97b899b6ae1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-07 (Sat, 07 Dec 2013) Changed paths: M KeyChain.package/SwitchUsers.class/instance/accessing/avatar.st M KeyChain.package/SwitchUsers.class/instance/initialize/initializeWidgets.st M KeyChain.package/SwitchUsers.class/instance/private/addUser.st M KeyChain.package/UserEditor.class/instance/accessing/avatar.st M Morphic-Base.package/MorphTreeListManager.class/instance/mouse managing/clicked_inTheCheckboxOf_.st M OpalCompiler-Core.package/extension/RBMethodNode/instance/primitiveFromPragma.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script284.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30629.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30629 12315 Menu World/System/Switch User raises Error and MNU https://pharo.fogbugz.com/f/cases/12315 12361 Bug in MorphTreeMorph if click is made on no item https://pharo.fogbugz.com/f/cases/12361 12345 Cleanup on more Opal methods https://pharo.fogbugz.com/f/cases/12345 http://files.pharo.org/image/30/30629.zip

Dec. 7, 2013

Re: [Pharo-dev] Pharo magic

by kilon alios

Welcome Nicolai. Actually small contributions is what most open source projects are made of since the majority of people don't have the luxury of free time or the motivation to contribute big chunks of code. But as It has been said it makes a huge difference because when you count in the amount of small contribution they make a rather big chunk of code. Plus if I ever encounter a bug fix or enhancement that makes my life easier there is no way I will be complaining about its size if you know what I mean ;D We have a saying here at Greece "water drops can crack even the hardest rock" which dates back to ancient Greece. On Sat, Dec 7, 2013 at 10:22 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 07 Dec 2013, at 00:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > This seems to be a good place to introduce myself. > > > > Welcome! > > > My Name is Nicolai Hess, > > I follow the squeak (and pharo) community for some years (~10). > > (Not as an *active* member in that time, but a little bit more the last > days:-) > > I am a software developer, most time working with c++ and java. > > Every time I start to dive into smalltalk world (again), > > even if all i have done are bugreports or small bugfixes, > > it impressed me how much more fun it makes. > > > Very nice small fixes :-) Thanks a lot for those! > > > Looking at smalltalks history I was always deeply impressed about all > > its development and *inventions*. > > (And a bit sad, it is not as recognized as it > > could be, and seeing how others again reinventing these things.) > > > > Yes, and it is important that we move the system forward so we are not > out-invented > by the worldâ¦ > > Marcus > > >

Dec. 7, 2013

Re: [Pharo-dev] Pharo magic

by Marcus Denker

On 07 Dec 2013, at 00:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > This seems to be a good place to introduce myself. > Welcome! > My Name is Nicolai Hess, > I follow the squeak (and pharo) community for some years (~10). > (Not as an *active* member in that time, but a little bit more the last days:-) > I am a software developer, most time working with c++ and java. > Every time I start to dive into smalltalk world (again), > even if all i have done are bugreports or small bugfixes, > it impressed me how much more fun it makes. > Very nice small fixes :-) Thanks a lot for those! > Looking at smalltalks history I was always deeply impressed about all > its development and *inventions*. > (And a bit sad, it is not as recognized as it > could be, and seeing how others again reinventing these things.) > Yes, and it is important that we move the system forward so we are not out-invented by the worldâ¦ Marcus

Dec. 7, 2013

Re: [Pharo-dev] Pharo magic

by StÃ©phane Ducasse

On Dec 7, 2013, at 12:23 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > This seems to be a good place to introduce myself. > > My Name is Nicolai Hess, > I follow the squeak (and pharo) community for some years (~10). > (Not as an *active* member in that time, but a little bit more the last days:-) > I am a software developer, most time working with c++ and java. > Every time I start to dive into smalltalk world (again), > even if all i have done are bugreports or small bugfixes, > it impressed me how much more fun it makes. yes and welcome on board. It can really change your life :) > > Looking at smalltalks history I was always deeply impressed about all > its development and *inventions*. > (And a bit sad, it is not as recognized as it > could be, and seeing how others again reinventing these things.) we should continue to invent because we have some advantages :) > It is great to see how pharo and the community moves on. > Thank you all. > > Nicolai > > > > 2013/12/6 Torsten Bergmann <astares(a)gmx.de> > Maybe others noticed the same: > > - the numbers of closed issues is amazing(see the news on the homepage) > - Pharo3.0 is already really usable and a pleasure to work with > - more and more nice projects appear on STHub and elsewhere > - more and more Pharo projects use continuous integration > - most projects and packages are loadable from the config browser and other places without > conflicting with each other > - there is so much activity regarding Pharo these days on mailinglists, bug-tracker, > twitter, conferences, blogs, stackoverflow, github ... it becomes hard to follow > but this is a good sign > - I see more and more fixes and improvements already as an update coming in before > I really realize that an own bug is needed because it improves the situation > - more and more new names appear on the dev and user mailinglist which is a good > sign that there is growing interest > - Pharo is on the right track and I like to be on the train > > Step by step it goes... > > Bye > T. > > > > >

Dec. 7, 2013

[pharo-project/pharo-core]

by GitHub

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

Dec. 7, 2013

[pharo-project/pharo-core] 683a1d: 30628

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 683a1deb6de486ec252053e0be2ba5d11dba5b33 https://github.com/pharo-project/pharo-core/commit/683a1deb6de486ec252053e0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-06 (Fri, 06 Dec 2013) Changed paths: M Fuel.package/FLDecoder.class/instance/accessing/classNamed_.st R GroupManager.package/AbstractGroup.class/instance/registry/unregister.st R GroupManager.package/GroupManager.class/README.md R GroupManager.package/GroupManager.class/class/accessing/current.st R GroupManager.package/GroupManager.class/class/accessing/setCurrentManager_.st R GroupManager.package/GroupManager.class/class/protocol/register_.st R GroupManager.package/GroupManager.class/class/protocol/unregister_.st R GroupManager.package/GroupManager.class/definition.st R GroupManager.package/GroupManager.class/instance/initialization/initialize.st R GroupManager.package/GroupManager.class/instance/registering/register_.st R GroupManager.package/GroupManager.class/instance/registering/unregister_.st M Komitter.package/KomitterUI.class/instance/initialization/initializeWidgets.st M Komitter.package/KomitterUI.class/instance/private/openRemoteManager.st A Komitter.package/KomitterUI.class/instance/private/remoteNodeFor_.st M Komitter.package/RemotesManager.class/instance/initialization/initializePresenter.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script283.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30628.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/OkCancelToolbar.class/instance/protocol/cancel.st A Spec-Core.package/OkToolbar.class/instance/protocol/cancel.st A Spec-Core.package/OkToolbar.class/instance/protocol/triggerCancelAction.st M Spec-Core.package/SpecDialogWindow.class/instance/actions/close.st A Spec-PolyWidgets.package/SearchableTree.class/instance/as yet unclassified /highlightedItem_.st Log Message: ----------- 30628 12308 GroupManager looks useless https://pharo.fogbugz.com/f/cases/12308 12348 Cleanup on some Fuel methods https://pharo.fogbugz.com/f/cases/12348 12362 Restrict the RemotesManager to the dirty packages https://pharo.fogbugz.com/f/cases/12362 12360 Add missing protocol to SearchableTree https://pharo.fogbugz.com/f/cases/12360 12359 Add missing protocol to OkToolbar https://pharo.fogbugz.com/f/cases/12359 http://files.pharo.org/image/30/30628.zip

Dec. 7, 2013

Re: [Pharo-dev] Responsible development

by Tudor Girba

Hi Yuriy, Loading a Moose model actually happens in a separate thread and you should be able to do other things in the meantime. However, it is true that the image becomes less responsive when doing that. Did you experience anything different? Doru -- www.tudorgirba.com "Every thing has its own flow." > On 02.12.2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > >> On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Uko2 wrote >>> Itâs not about stability of pharo 3, it about concurrency... This thread >>> doesnât seem to have any reason >> >> Nothing is wasted. I appreciate your ideas. I never thought of these >> benefits; I always took it for granted to run in one thread. > > Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. > > Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. > > uko > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 7, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

I agree but that is a problem inherent to the current implementation and itâs not really my goal now to fix all the shortcomings :) I simply want a consistent way to get through this (since Iâve heard that the streams might be replaced with Xtreamsâ¦). On 07.12.2013, at 00:44, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hem, switching #ascii <-> #binary does only make sense in... ASCII > With every other encoding, it's not something that makes sense at all, or maybe #latin1 <-> #binary, #utf8 <-> #binary, #utf16 <-> #binary > > > 2013/12/5 Max Leske <maxleske(a)gmail.com> > There are several different approaches in different places: > > - FileStream reads strings by default. #binary and #ascii switch between formats. File streams use an internal buffer which is either a String (default) or a ByteArray. Itâs even possible to switch between binary and ascii midstream without losing information (if done right) because it only affects the buffer. > - ReadStream and WriteStream cannot change their format. Their behavior is determined by the underlying collection. Forcing conversions (e.g. by #asString) can lead to loss of information > - RWBinaryOrTextStream (and other subclasses of ReadWriteStream) also support the #binary #ascii method of switching format. Default is #ascii > - SocketStream uses the same #binary / #ascii mechanism. Default is #ascii > - ZnLimitedReadStream uses the same #binary / #ascii mechanism. Default is #binary (implicit); depends on the underlying stream > > I think the pattern to follow is clear: ReadStream and WriteStream should allow switching format with #ascii and #binary, default should be #ascii. However, I suspect thereâs a reason that these classes donât support switching, namely that switching makes the implementation more complicated and also slower because more checks need to be made. > > The easiest solution I see would be to implement something like this: > > ReadStream>>next > ^ self isBinary > ifTrue: [ self basicNext asCharacter ] > ifFalse: [ self basicNext ] > > However, #next et al. are implemented in a plugin and the primitive method looks like this: > > ReadStream>>next > <primitive: 65> > position >= readLimit > ifTrue: [^nil] > ifFalse: [^collection at: (position := position + 1)] > > This means the collection instance variable has to hold either a binary or a string collection. > > Iâve found a solution which would work and Iâve whipped up a working way (thereâs space for improvementâ¦): > > ReadStream>>binary > collection isString ifFalse: [ ^ self ]. > collection := (ByteArray new: collection size) copyReplaceFrom: 1 to: collection size with: collection > > ReadStrem>>ascii > collection isString ifTrue: [ ^ self ]. > collection := (String new: collection size) copyReplaceFrom: 1 to: collection size with: collection > > @Damien > opposed to what I wrote earlier, #asString does *not* destroy non-printable characters. Instead, every byte (from 0 to 255) is encoded as a character and thus the string can be converted back to a ByteArray *without* loss of information. Sorry about that. > > With this change in place the 12259 would become obsolete. > > Please let me know what you think. This is a pretty big change that might have a lot of consequences in the image. > > Cheers, > Max > > On 04.12.2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > >> Let me see what I can come up with. >> >> >> On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content >>> >>> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: >>> Damien, Marcus >>> >>> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. >>> >>> Cheers, >>> Max >> > >

Dec. 7, 2013