- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] pillar latex and code listings

by Nicolai Hess

2016-11-21 15:17 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: > I finally remembered to have a quick lookâ¦ there is one named and > referenced script in the Pillar chapter in EnterprisePharo. Look for > occurrences of "my script" > Ok, thank you Damien. What is the most "stable" :-) version of sbabook ? PharoByExample uses sbabook @ b1ad4b4 <https://github.com/cdlm/sbabook/tree/b1ad4b4f9a2ac2b2b6ae0a16f03e68e4d22ff5…> EnterprisePharo uses sbabook @ bf4509f <https://github.com/cdlm/sbabook/tree/bf4509fa87b1987f6f9a49edddb4e2ac9910b9…> nicolai > > On 13 November 2016 at 22:53, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> >> >> 2016-11-13 22:16 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: >> >>> On 13 November 2016 at 16:23, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> Hi Damien, I don't see how the layout from the EnterprisePharo could do >>>> labeled listings we could ref from the text. May it be that this is just >>>> not possible ? >>> >>> >>> I recall we discussed choices with the other Damien, and that there were >>> constraints due to listings.sty, but I think that's possible. I'd have to >>> have a look at the code, though, because it's very well possible that we >>> decided on a workaround instead. >>> >>> Can you catch me on Slack sometime this week, or open an issue on >>> https://github.com/cdlm/sbabook if not? >>> >> >> Ok, thanks. >> >> >> >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >> >> >> >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Nov. 27, 2016

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

by stepharo

On Sat, 26 Nov 2016 23:16:50 +0100, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi, > >> I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x >> under Mingw). >> If you have a GCC5 instead of the old 4.6, I am interested in your >> config. > Now I am building in Windows using both, MinGW version 4.9.3, and Visual > Studio 2015 Community Edition. > > I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the > -headless parameter is for the image to quit after finishing). > When running a normal Pharo.image, I am getting a FFI related crash > (with Visual Studio and MinGW), when the image tries to read the APPDATA > environment variable. > > Right now I am using the same main function for both, the Unix and Win32 > VM. This means, that we are close of having the embedded version. I love that :) > > > In windows I am build two variants of the VM, pharo.exe (or squeak.exe) > and pharow.exe (or squeakw.exe). The executable without the w is a > console program, so it can >use stdin, stdout and stderr. The executable > with the w is a windows program that does not create a console window on > startup, but it cannot use stdout, stderr, or stdin. >This is the > standard workaround for an annoying limitation of Windows itself (Python > does the same in windows, with the same nomenclature). Yes this is on the roadmap of esteban but he got killed by vm merge + UFFI > > > Visual Studio is unstable than MinGW, but it has an excellent debugger. > With Visual Studio, I am getting some false positives for an assertion > because they get >miscompiled. For some reason, the > assert(GIV(remapBufferCount) == 0) gets compiled into the same as > assert(GIV(remapBufferCount)). Apart from this assertion, these >two > versions of the VM are crashing in the same place. > >> >> Fantastic, except: >> >>> >>> - Unified standard CMake building scripts for Unixes. I hate autoconf. >>> I want to use them in Windows too. >> >> We have agreed that we will use makefiles and restrict make to >> generating platform config.h files that define platform facilities. I >> have very good reasons for doing this. I >>have discussed this at >> length this year. Please don't make me argue this all over again. >> ... >> [goodness deleted] > I cannot just use makefile, because I am also compiling in Windows using > Visual Studio 2015 Community Edition, by generating the visual studio > projects with CMake. I >looked for the older discussions on the mailing > lists, I could not find, a long discussion on the mailing list, except > for several short ones. > I have also seen some projects(LLVM, Boost) that have more than one > build system, an official based on autoconf(or something else), and an > alternative based on CMake. > > As for the config.h, I can also generate it using CMake, and I will > start doing it now because I think that it is related to the FFI > crashing issues that I am experimenting on >Windows. Currently I am > already using CMake for generating the git version string. As long as > git is in the path and cmake founds it, the header with the version > string is >generated correctly, even when using the Visual Studio > projects. > > Anyway, I am not using the old CMakeVMMaker that Igor did(and I just > learned about Ian CMake work by finding in the mailing list). I just > adapted the plain CMake scripts >that I normally use for building my own > projects to build the VM. > >> Are you on board? Would you like to discuss this on skype or >> somewhere? > Sure we can discuss it, I am on chile so we are not far apart in time > zones. > > As long as building the VM can be done automatically in Unixes by > running a short number of commands, that work most of the time, I am OK > with it. > As for Windows, it has to be possible to use Visual Studio in addition > to MinGW or Cygwin. Visual Studio is required to be able to build for > the Universal Windows Platform, >and getting the VM working in a retail > XBox One ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index > ). > > Best regards, > Ronie > > 2016-11-26 14:09 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>Hi Roni, >> >> >> On Nov 23, 2016, at 11:12 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: >> >>> Hello, >>> >>> I am working on removing most of windowing code from the VM, and in >>> trying to unify the platform specific code of the VM. In the >>> MinimalistHeadless >>>branch of >>> https://github.com/ronsaldo/opensmalltalk-vm I made the following >>> changes: >> >> Fantastic, except: >> >>> >>> - Unified standard CMake building scripts for Unixes. I hate autoconf. >>> I want to use them in Windows too. >> >> We have agreed that we will use makefiles and restrict make to >> generating platform config.h files that define platform facilities. I >> have very good reasons for doing this. I >>have discussed this at >> length this year. Please don't make me argue this all over again. Are >> you on board? Would you like to discuss this on skype or somewhere? >> ... >> [goodness deleted] >> >>> Does it make sense, to always trying to create a display in startup >>> time? >> >> Good question. The answer should be "no" but that only makes sense if >> the system is written to not depend on a display when in headless mode. >> >>> >>> Best regards, >>> Ronie >> > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 27, 2016

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

by Ronie Salgado

Hi, I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x under > Mingw). > If you have a GCC5 instead of the old 4.6, I am interested in your config. > Now I am building in Windows using both, MinGW version 4.9.3, and Visual Studio 2015 Community Edition. I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the -headless parameter is for the image to quit after finishing). When running a normal Pharo.image, I am getting a FFI related crash (with Visual Studio and MinGW), when the image tries to read the APPDATA environment variable. Right now I am using the same main function for both, the Unix and Win32 VM. This means, that we are close of having the embedded version. In windows I am build two variants of the VM, pharo.exe (or squeak.exe) and pharow.exe (or squeakw.exe). The executable without the w is a console program, so it can use stdin, stdout and stderr. The executable with the w is a windows program that does not create a console window on startup, but it cannot use stdout, stderr, or stdin. This is the standard workaround for an annoying limitation of Windows itself (Python does the same in windows, with the same nomenclature). Visual Studio is unstable than MinGW, but it has an excellent debugger. With Visual Studio, I am getting some false positives for an assertion because they get miscompiled. For some reason, the assert(GIV(remapBufferCount) == 0) gets compiled into the same as assert(GIV(remapBufferCount)). Apart from this assertion, these two versions of the VM are crashing in the same place. > Fantastic, except: > > > - Unified standard CMake building scripts for Unixes. I hate autoconf. I > want to use them in Windows too. > > > We have agreed that we will use makefiles and restrict make to generating > platform config.h files that define platform facilities. I have very good > reasons for doing this. I have discussed this at length this year. Please > don't make me argue this all over again. > ... > [goodness deleted] > I cannot just use makefile, because I am also compiling in Windows using Visual Studio 2015 Community Edition, by generating the visual studio projects with CMake. I looked for the older discussions on the mailing lists, I could not find, a long discussion on the mailing list, except for several short ones. I have also seen some projects(LLVM, Boost) that have more than one build system, an official based on autoconf(or something else), and an alternative based on CMake. As for the config.h, I can also generate it using CMake, and I will start doing it now because I think that it is related to the FFI crashing issues that I am experimenting on Windows. Currently I am already using CMake for generating the git version string. As long as git is in the path and cmake founds it, the header with the version string is generated correctly, even when using the Visual Studio projects. Anyway, I am not using the old CMakeVMMaker that Igor did(and I just learned about Ian CMake work by finding in the mailing list). I just adapted the plain CMake scripts that I normally use for building my own projects to build the VM. Are you on board? Would you like to discuss this on skype or somewhere? Sure we can discuss it, I am on chile so we are not far apart in time zones. As long as building the VM can be done automatically in Unixes by running a short number of commands, that work most of the time, I am OK with it. As for Windows, it has to be possible to use Visual Studio in addition to MinGW or Cygwin. Visual Studio is required to be able to build for the Universal Windows Platform, and getting the VM working in a retail XBox One ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index ). Best regards, Ronie 2016-11-26 14:09 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Roni, > > > On Nov 23, 2016, at 11:12 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hello, > > I am working on removing most of windowing code from the VM, and in trying > to unify the platform specific code of the VM. In the MinimalistHeadless > branch of https://github.com/ronsaldo/opensmalltalk-vm I made the > following changes: > > > Fantastic, except: > > > - Unified standard CMake building scripts for Unixes. I hate autoconf. I > want to use them in Windows too. > > > We have agreed that we will use makefiles and restrict make to generating > platform config.h files that define platform facilities. I have very good > reasons for doing this. I have discussed this at length this year. Please > don't make me argue this all over again. Are you on board? Would you like > to discuss this on skype or somewhere? > ... > [goodness deleted] > > Does it make sense, to always trying to create a display in startup time? > > > Good question. The answer should be "no" but that only makes sense if the > system is written to not depend on a display when in headless mode. > > > Best regards, > Ronie > > >

Nov. 26, 2016

Re: [Pharo-dev] feature request for GTSUnitDebugger

by Denis Kudriashov

2016-11-26 20:55 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Right now there is 'Jump to test method' in the toolbar menu of the stack > (the drop down arrow next to Through). > Thank's for hint > Could maybe make sense to make it an actual button. > I think it would be usefull

Nov. 26, 2016

Is extract method still working?

by stepharo

Hi on this expression when I select KeyedTree new at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself I get an error because the method extracted look like the following. at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself testSubtrees "Test the subtrees method for success and failure modes." | t1 t2 t3 t4 | t1 := KeyedTree new at: 1 put: (t2 := KeyedTree new at: 1 put: '1-1'; at: 2 put: '1-2'; at: 3 put: (t3 := KeyedTree new at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself); yourself); at: 2 put: '2'; at: 3 put: (t4 := KeyedTree new at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself); yourself. I wonder if something change in the AST. --

Nov. 26, 2016

Re: [Pharo-dev] feature request for GTSUnitDebugger

by Andrei Chis

Hi, Right now there is 'Jump to test method' in the toolbar menu of the stack (the drop down arrow next to Through). Could maybe make sense to make it an actual button. Cheers, Andrei On Sat, Nov 26, 2016 at 8:23 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I catch myself that I very often scroll stack view in debugger just to see > test method. > It would be nice to have test tab and "show test" button. > > Best regards, > Denis >

Nov. 26, 2016

feature request for GTSUnitDebugger

by Denis Kudriashov

Hello. I catch myself that I very often scroll stack view in debugger just to see test method. It would be nice to have test tab and "show test" button. Best regards, Denis

Nov. 26, 2016

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

by Eliot Miranda

Hi Roni, > On Nov 23, 2016, at 11:12 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hello, > > I am working on removing most of windowing code from the VM, and in trying to unify the platform specific code of the VM. In the MinimalistHeadless branch of https://github.com/ronsaldo/opensmalltalk-vm I made the following changes: Fantastic, except: > > - Unified standard CMake building scripts for Unixes. I hate autoconf. I want to use them in Windows too. We have agreed that we will use makefiles and restrict make to generating platform config.h files that define platform facilities. I have very good reasons for doing this. I have discussed this at length this year. Please don't make me argue this all over again. Are you on board? Would you like to discuss this on skype or somewhere? ... [goodness deleted] > Does it make sense, to always trying to create a display in startup time? Good question. The answer should be "no" but that only makes sense if the system is written to not depend on a display when in headless mode. > > Best regards, > Ronie

Nov. 26, 2016

Re: [Pharo-dev] LinkedList>>#containsCycle

by stepharo

Hi doru > Hi Stef, > > Would it make sense to put the collection extensions from Moose in the > Container project? If you think it make sense. Yes. For example Ropes could be managed there. Have a look I have tiny packages. The idea is to make sure that - people can use one abstraction and not be forced to load a complete library - document them with tests and others - gather most of collections in one place to make sure that we do not lose energy reimplementing them. I'm packaging the collection from the image that have no users in the image for now. Then I will continue to package a Tree package (I tried to contact his author but may be he passed away) SkipList Quadtrees. Stef > > Cheers, > Doru > > >> On Nov 26, 2016, at 12:11 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi Sven >> >> I'm collecting alternative Collection implementations in the project >> Container >> I do not remember if I have linkedList but we can add it there. >> >> You may wonder why I'm doing that? >> - I want to be able to have strong collections that are independent >> from the kernel >> - Ideally the kernel of Pharo should be mininmal so it means that I >> would like to >> have as few as possible as collections inside the bootstrapped kernel >> and that other collections are nicely packaged in Container. >> >> Now I can understand that others do not like what I'm doing but I will >> just continue. >> I have Grid, LinkedList, DoubleLinkedList, >> I have on my disc >> two implementation of Trees >> I should harvest BTrees and SkipList. >> >> If people want to help they are welcome, else I will just do it alone. >> >> Stef >> >>> Hi, >>> >>> There exists a very elegant algorithm to detect cycles in linked lists. >>> >>> https://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare >>> >>> I know that our LinkedList was written with the assumption that there >>> are no cycles. However, it seems to me that it would be nice to have a >>> test to check for cycles. This could be useful while printing or >>> inspecting a LinkedList (and prevent things from blowing up when there >>> is a cycle). >>> >>> Here is the implementation: >>> >>> LinkedList>>#containsCycle >>> | slow fast | >>> slow := fast := firstLink. >>> [ slow notNil and: [ fast notNil and: [ fast nextLink notNil ] ] ] >>> whileTrue: [ >>> slow := slow nextLink. >>> fast := fast nextLink nextLink. >>> slow == fast >>> ifTrue: [ ^ true ] ]. >>> ^ false >>> >>> And one of the tests: >>> >>> LinkedListTests>>#testCycles >>> 1 to: 42 do: [ :each | >>> list := LinkedList withAll: (1 to: each). >>> "Warning: the following statement creates a cylce, >>> inspecting/viewing list will probably fail" >>> list lastLink nextLink: list firstLink. >>> self assert: list containsCycle ] >>> >>> Opinions ? >>> >>> Sven >>> >>> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 26, 2016

Re: [Pharo-dev] LinkedList>>#containsCycle

by Tudor Girba

Hi Stef, Would it make sense to put the collection extensions from Moose in the Container project? Cheers, Doru > On Nov 26, 2016, at 12:11 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi Sven > > I'm collecting alternative Collection implementations in the project Container > I do not remember if I have linkedList but we can add it there. > > You may wonder why I'm doing that? > - I want to be able to have strong collections that are independent from the kernel > - Ideally the kernel of Pharo should be mininmal so it means that I would like to > have as few as possible as collections inside the bootstrapped kernel > and that other collections are nicely packaged in Container. > > Now I can understand that others do not like what I'm doing but I will just continue. > I have Grid, LinkedList, DoubleLinkedList, > I have on my disc > two implementation of Trees > I should harvest BTrees and SkipList. > > If people want to help they are welcome, else I will just do it alone. > > Stef > >> Hi, >> >> There exists a very elegant algorithm to detect cycles in linked lists. >> >> https://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare >> >> I know that our LinkedList was written with the assumption that there are no cycles. However, it seems to me that it would be nice to have a test to check for cycles. This could be useful while printing or inspecting a LinkedList (and prevent things from blowing up when there is a cycle). >> >> Here is the implementation: >> >> LinkedList>>#containsCycle >> | slow fast | >> slow := fast := firstLink. >> [ slow notNil and: [ fast notNil and: [ fast nextLink notNil ] ] ] >> whileTrue: [ >> slow := slow nextLink. >> fast := fast nextLink nextLink. >> slow == fast >> ifTrue: [ ^ true ] ]. >> ^ false >> >> And one of the tests: >> >> LinkedListTests>>#testCycles >> 1 to: 42 do: [ :each | >> list := LinkedList withAll: (1 to: each). >> "Warning: the following statement creates a cylce, >> inspecting/viewing list will probably fail" >> list lastLink nextLink: list firstLink. >> self assert: list containsCycle ] >> >> Opinions ? >> >> Sven >> >> > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

Nov. 26, 2016