- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Many problems with Iceberg :-(

by Damien Pollet

Same for me. While Iceberg is in development, I have to rely on gitfiletree and command-line git to have some control over the repo. On 23 September 2016 at 11:23, Norbert Hartl <norbert(a)hartl.name> wrote: > I really like this to work. I'm not sure my reports are useful at all. If > I should report detailed stuff or should try something just drop me a note. > > thanks for making iceberg. Until now I've seen just the tip of it ;) > > Norbert > > Am 23.09.2016 um 10:57 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > Thanks, Norbert. > > On Fri, Sep 23, 2016 at 10:46 AM, Norbert Hartl <norbert(a)hartl.name> > wrote: > >> No, >> >> I unloaded the code and reloaded the development version. My error is >> slightly different. I use a repository that is having a filetree repository >> (or gitfiletree) and that I try to open with iceberg >> >> Norbert >> >> >> <Bildschirmfoto 2016-09-23 um 10.43.46.png> >> >> Am 23.09.2016 um 00:07 schrieb Alexandre Bergel <alexandre.bergel(a)me.com >> >: >> >> Hi! >> >> I am facing several bugs using Iceberg. >> Am I the only one? >> >> <Screen Shot 2016-09-22 at 7.06.08 PM.png> >> <Screen Shot 2016-09-22 at 7.06.18 PM.png> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

by Marcus Denker

> On 23 Sep 2016, at 08:25, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> >> 19124 enhance Deprecation to log sending method >> https://pharo.fogbugz.com/f/cases/19124 > > > The result of this is that now the log on the CI now exactly tells us what to fix: > (I will add issue tracker entries for each): > They are now all added as subclasses of https://pharo.fogbugz.com/f/cases/18702/ <https://pharo.fogbugz.com/f/cases/18702/> Marcus

Sept. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] d87de4: 60237

by Marcus Denker

> On 23 Sep 2016, at 11:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> >> Log Message: >> ----------- >> 60237 >> Moose >> >> http://files.pharo.org/image/60/60237.zip >> >> > > This is: > > - case 19032 > - testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was failing due to #isLastInOwner > - add manifest wit preUnload action in GTDebugger > > But: > > => 19032 seems to be not fixed. (there is still a sender if #ifNotNilDo:) > > => the gt problem with testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was fixed, but in the meantime > we got more problems (from epicea). This is a nice example how not fixing a trivial bug leads to more decay fast > that we do not even know about. âyes, that test fails and I know why. Will be fixed when we mergeâ. > What happens instead is that this âknown failureâ will fail soon due to many more other reasonsâ¦ that nobody is > even aware of. > > Trivial is not trivial.. that is why one needs to fix them as soon as possible and *never* think that batching trivialities is > a good ideaâ¦ > Issue tracker entries are updated. (closed / edited so reflect what is left to be done) Marcus

Sept. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] d87de4: 60237

by Marcus Denker

> > Log Message: > ----------- > 60237 > Moose > > http://files.pharo.org/image/60/60237.zip > > This is: - case 19032 - testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was failing due to #isLastInOwner - add manifest wit preUnload action in GTDebugger But: => 19032 seems to be not fixed. (there is still a sender if #ifNotNilDo:) => the gt problem with testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was fixed, but in the meantime we got more problems (from epicea). This is a nice example how not fixing a trivial bug leads to more decay fast that we do not even know about. âyes, that test fails and I know why. Will be fixed when we mergeâ. What happens instead is that this âknown failureâ will fail soon due to many more other reasonsâ¦ that nobody is even aware of. Trivial is not trivial.. that is why one needs to fix them as soon as possible and *never* think that batching trivialities is a good ideaâ¦ Marcus

Sept. 23, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 23, 2016

[pharo-project/pharo-core] d87de4: 60237

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d87de481a22f9fdc663f44726cd6e9f2fede217a https://github.com/pharo-project/pharo-core/commit/d87de481a22f9fdc663f4472… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-23 (Fri, 23 Sep 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version32_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version320_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version316_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version217_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version328_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version422_.st A GT-Debugger.package/ManifestGTDebugger.class/README.md A GT-Debugger.package/ManifestGTDebugger.class/class/unloading/preUnload.st A GT-Debugger.package/ManifestGTDebugger.class/definition.st M GT-Playground.package/GTPlayground.class/instance/building/compose.st R Glamour-Morphic-Brick.package/GLMBrick.class/instance/brick-structure-testing/isLastInOwner.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60236.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60237.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60236.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60237.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60237 Moose http://files.pharo.org/image/60/60237.zip

Sept. 23, 2016

Re: [Pharo-dev] Many problems with Iceberg :-(

by Norbert Hartl

I really like this to work. I'm not sure my reports are useful at all. If I should report detailed stuff or should try something just drop me a note. thanks for making iceberg. Until now I've seen just the tip of it ;) Norbert > Am 23.09.2016 um 10:57 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > Thanks, Norbert. > > On Fri, Sep 23, 2016 at 10:46 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > No, > > I unloaded the code and reloaded the development version. My error is slightly different. I use a repository that is having a filetree repository (or gitfiletree) and that I try to open with iceberg > > Norbert > > > <Bildschirmfoto 2016-09-23 um 10.43.46.png> >> Am 23.09.2016 um 00:07 schrieb Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: >> >> Hi! >> >> I am facing several bugs using Iceberg. >> Am I the only one? >> >> <Screen Shot 2016-09-22 at 7.06.08 PM.png> >> <Screen Shot 2016-09-22 at 7.06.18 PM.png> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > >

Sept. 23, 2016

Re: [Pharo-dev] Many problems with Iceberg :-(

by Nicolas Passerini

Thanks, Norbert. On Fri, Sep 23, 2016 at 10:46 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > No, > > I unloaded the code and reloaded the development version. My error is > slightly different. I use a repository that is having a filetree repository > (or gitfiletree) and that I try to open with iceberg > > Norbert > > > > Am 23.09.2016 um 00:07 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > I am facing several bugs using Iceberg. > Am I the only one? > > <Screen Shot 2016-09-22 at 7.06.08 PM.png> > <Screen Shot 2016-09-22 at 7.06.18 PM.png> > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Sept. 23, 2016

Re: [Pharo-dev] Many problems with Iceberg :-(

by Norbert Hartl

No, I unloaded the code and reloaded the development version. My error is slightly different. I use a repository that is having a filetree repository (or gitfiletree) and that I try to open with iceberg Norbert > Am 23.09.2016 um 00:07 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > I am facing several bugs using Iceberg. > Am I the only one? > > <Screen Shot 2016-09-22 at 7.06.08 PM.png> > <Screen Shot 2016-09-22 at 7.06.18 PM.png> > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

Sept. 23, 2016

Re: [Pharo-dev] C Variadic Functions via UFFI?

by Esteban Lorenzano

along with what Andres says, also no, you do not have support for variadic functions. what you do this is to declare your functions as if they were non-variadic: pritnf: format intValue: number self ffiCall: #(int printf(String format, int number)) that will workâ¦ yes is not the best in the word, but it works :) Esteban > On 23 Sep 2016, at 08:11, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > > I wouldn't do that if I were you. The manual says fcntl() can be a macro, and you can't call a macro from an FFI. > > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/fcntl.h.html > > On 9/22/16 15:12 , Mariano Martinez Peck wrote: >> Hi guys, >> >> I am wondering if I can wrap some variadic functions (with optional >> arguments) with UFFI. Is this possible? If true, how so? For my >> particular use case, I am checking if I can call fcntl() >> which has a third optional argument. >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >

Sept. 23, 2016