Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux
On 26 March 2017 at 04:09, Pierce Ng wrote: > On Sat, Mar 25, 2017 at 07:29:29PM +0100, Alistair Grant wrote: >> make[3]: *** No rule to make target >> '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.23.0'. > > Sorry, also > > % sudo apt-get install libssl-dev:i386 Thanks, Pierce. That gets past the previous errors, I'm now getting: ... Installing links /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build cp -f /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libssh2.so.1.0.1 /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- Installing links DONE /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build cp -f /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- Installing links DONE /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build can't find PharoV50.sources I haven't used travis, but it looks like it is defining a number of environment variables, e.g. ARCH, FLAVOR, SRC_ARCH, HEARTBEAT. If I want the 32 bit linux threaded heartbeat, do I need to set these manually? Thanks again, Alistair
[Pharo-users] Creating Dates before/after Daylight Saving Time change
Hello, 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code: D1 := Date year: 2017 month: 3 day: 26. Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00 2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change): D2 := Date year: 2017 month: 3 day: 26. Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00 3) D1 != D2 So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :( Is it OK? Thanks! Petr Fischer
Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux
> On 26 Mar 2017, at 09:10, Alistair Grant wrote: > > On 26 March 2017 at 04:09, Pierce Ng wrote: >> On Sat, Mar 25, 2017 at 07:29:29PM +0100, Alistair Grant wrote: >>> make[3]: *** No rule to make target >>> '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.23.0'. >> >> Sorry, also >> >> % sudo apt-get install libssl-dev:i386 > > Thanks, Pierce. > > That gets past the previous errors, I'm now getting: > > ... > Installing links > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > cp -f > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libssh2.so.1.0.1 > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- > Installing links > DONE > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > cp -f > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- > Installing links > DONE > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > can't find PharoV50.sources > > > I haven't used travis, but it looks like it is defining a number of > environment variables, e.g. ARCH, FLAVOR, SRC_ARCH, HEARTBEAT. If I > want the 32 bit linux threaded heartbeat, do I need to set these > manually? no, once compiled is done (and your compilation worked). those variables are for travis consumption, to allow use to pick the right artifact to build, but you already did it by hand :) Esteban > > Thanks again, > Alistair >
Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change
Date>>year:month:day: (respectively Date>>#starting:) is using DateAndTime to specify the start, and DateAndTime will of course differ. To me it seems like someone was reusing implementation; because Date normally shouldn't have/care about time information, and yet it subclasses from Timespan class, which has/cares about time information. So the Date is actually encoded in Timespan's 'starting' instVar as DateAndTime instance, which is obviously breaking if TimeZone is applied. Maybe a fix (apart from not using Time in Date) would be to make sure Date's methods use DateAndTime offset to 0? Because even without daylight saving, if you create a Date instance in one country, and move to different TZ it should break; so always keeping it UTC/0 would make sense to me. Peter On Sun, Mar 26, 2017 at 10:17:14AM +0200, Petr Fischer wrote: > Hello, > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) > with this code: > > D1 := Date year: 2017 month: 3 day: 26. > > Date object is created with instvars: > start: 2017-03-26T00:00:00+01:00 > duration: 1:00:00:00 > > 2) when I create same Date instance with the same code on/after: 2017/03/26 > (after Daylight Saving Time change): > > D2 := Date year: 2017 month: 3 day: 26. > > Date instance with this instvars returned: > start: 2017-03-26T00:00:00+02:00 > duration: 1:00:00:00 > > 3) D1 != D2 > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: > 26) created before DST change is not equal with date instance (Date year: > 2017 month: 3 day: 26) created after DST change. > DST change breaks equality of the same date :( > > Is it OK? > > Thanks! Petr Fischer >
Re: [Pharo-users] Installing Voyage ??
I get that same problem, too, every time I do "Software update". But never understood the rationale of dropping a database at this point. I think we should remove this line Norbert > Am 25.03.2017 um 22:04 schrieb Hilaire : > > ah yeah, I wrote an internal durty hack to get it rolling > > cleanUp: aRepository > (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase] > > >> Le 25/03/2017 à 21:46, Hilaire a écrit : >> It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my >> image, I don't remember. > > -- > Dr. Geo > http://drgeo.eu > >
Re: [Pharo-users] Voyage Timeout
Indeed. It was just I was in the middle of something. Le 25/03/2017 à 19:10, Stephane Ducasse a écrit : > you should think to move to Pharo 50. We closed around 1500 issues between > pharo 40 and pharo 50 and the same amount between pharo 50 and pharo 60. > Pharo 50 is really stable and working well -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux
On Sun, Mar 26, 2017 at 3:10 PM, Alistair Grant wrote: > On 26 March 2017 at 04:09, Pierce Ng wrote: >> On Sat, Mar 25, 2017 at 07:29:29PM +0100, Alistair Grant wrote: >>> make[3]: *** No rule to make target >>> '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.23.0'. >> >> Sorry, also >> >> % sudo apt-get install libssl-dev:i386 > > Thanks, Pierce. > > That gets past the previous errors, I'm now getting: > > ... > Installing links Is there text cut from the right side of these lines. The next three lines are repeated, but maybe there was something more to distinguish them? Also line 5 "squeak/5.0-" seems cut off. > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > cp -f > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libssh2.so.1.0.1 > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- > Installing links > DONE > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > cp -f > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/***products***/phcogspurlinuxht/lib/squeak/5.0- Check whats under the ***products*** folder I marked above. > Installing links > DONE > /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > can't find PharoV50.sources PharoV50.sources [1] needs to sit next to the VM or Image files to be found. "can't find" it, is a standard message from a running VM. Could you report if this works for you... https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/79 cheers -ben > > > I haven't used travis, but it looks like it is defining a number of > environment variables, e.g. ARCH, FLAVOR, SRC_ARCH, HEARTBEAT. If I > want the 32 bit linux threaded heartbeat, do I need to set these > manually? > > Thanks again, > Alistair >
[Pharo-users] using UFFI in non-crashing way
Hi, is it possible to use UFFI and avoid crashing the image when the called code segfaults? In other words, can I somehow wrap the call and throw in-image Exception/Error on failure instead of the whole thing crashing? Or is the only way to do that have the called thing running as a separate app (e.g. via OSSubProcess) and communicate via pipes or sockets? Thanks, Peter
Re: [Pharo-users] Smalltalk on Stack Overflow Developers Survey 2017
On 26/03/17 04:16, Pierce Ng wrote: On Sat, Mar 25, 2017 at 07:56:03PM +0100, Stephan Eggermont wrote: On 25/03/17 18:29, serge.stinckw...@gmail.com wrote: Nice ! But do you have a way to automatize this process ? ;-) How difficult can it be? We did it 18 years ago in java & delphi :) I was going to answer 'Hadoop!', then went to SO and saw your (Stephan's) meta-comment on moderators who closed a question on big data in Smalltalk. Heh. Yeah. On SO, state you are doing big data with pharo and ask a very specific question. On the best way to detect hanging images or so. Stephan
Re: [Pharo-users] using UFFI in non-crashing way
> On 26 Mar 2017, at 15:40, Peter Uhnak wrote: > > Hi, > > is it possible to use UFFI and avoid crashing the image when the called code > segfaults? > > In other words, can I somehow wrap the call and throw in-image > Exception/Error on failure instead of the whole thing crashing? that’s not possible, once you segfault, you segfault. > Or is the only way to do that have the called thing running as a separate app > (e.g. via OSSubProcess) and communicate via pipes or sockets? that’s not done. no idea how much effort is required to implement, but I imagine is not trivial. Esteban > > Thanks, > Peter >
Re: [Pharo-users] Smalltalk on Stack Overflow Developers Survey 2017
Big data, like the ‘cloud’, is mainly a marketing thing to sell big iron in big datacenters. So if you’re going back to big iron anyway, might as well use VisualGen for COBOL. What? VisualGen is written in IBM Smalltalk? Just don’t tell anyone, they’ll never guess. Andrew On 2017-03-26, 11:43 AM, "Pharo-users on behalf of Stephan Eggermont" wrote: On 26/03/17 04:16, Pierce Ng wrote: > On Sat, Mar 25, 2017 at 07:56:03PM +0100, Stephan Eggermont wrote: >> On 25/03/17 18:29, serge.stinckw...@gmail.com wrote: >>> Nice ! But do you have a way to automatize this process ? ;-) >> How difficult can it be? We did it 18 years ago in java & delphi :) > > I was going to answer 'Hadoop!', then went to SO and saw your (Stephan's) > meta-comment on moderators who closed a question on big data in Smalltalk. > Heh. Yeah. On SO, state you are doing big data with pharo and ask a very specific question. On the best way to detect hanging images or so. Stephan
Re: [Pharo-users] using UFFI in non-crashing way
> Hi, > > is it possible to use UFFI and avoid crashing the image when the called > code segfaults? > > Yes its possible. When I was exploring the means to live code with C++ I came to specific implementations of live coding for C++. One of them explored a feature called "Hardware exceptions" .Hardware exceptions are very similar to regular exception with the big difference that are handled by the CPU and not the language or the OS. Crashes is a standard behavior that is imposed by the OS kernel in the case that an app tries to access memory is not allowed to access or access it in the way it is not allowed to access it. An exception will capture this behavior it wont allow the application to crash. Hardware exceptions are a standard feature for most CPUs and obviously they are not implemented at language level. For example you can find documentation about Hardware exceptions on Windows at https://msdn.microsoft.com/en-us/library/windows/desktop/ms680657(v=vs.85).aspx This means the C code you will be calling with UFFI will have to be wrapped inside a Hardware exception. When a crash is suppose to happen inside code that is wrapped with a hardware exception, the error (seffault in your example) will be displayed in the console but the application wont crash it will continue to execute depending on how you handle the exception. Generally hardware exception are to be avoided because they can hide bugs because the OS not always reports and can crash an app without an error in that you will be oblivious to what went wrong, when and how as the crash will not happen. > In other words, can I somehow wrap the call and throw in-image > Exception/Error on failure instead of the whole thing crashing? > > Its possible if you make a C function that contains a hardware exception take as argument a pointer to a specific function and then calls it inside the exception. > Or is the only way to do that have the called thing running as a separate > app (e.g. via OSSubProcess) and communicate via pipes or sockets? > It wont make a diffirence if the crash is caused by UFFI it will still crash Pharo that applies even if you use hardware exceptions , so you need always to be careful. Plus Pharo VM at any point can crash for its own reason, that is completely unrelated to what you are doing Thanks, > Peter > So yes its possible, but you still need to be careful.
Re: [Pharo-users] using UFFI in non-crashing way
On Sun, Mar 26, 2017 at 05:45:04PM +0200, Esteban Lorenzano wrote: > > > On 26 Mar 2017, at 15:40, Peter Uhnak wrote: > > > > Hi, > > > > is it possible to use UFFI and avoid crashing the image when the called > > code segfaults? > > > > In other words, can I somehow wrap the call and throw in-image > > Exception/Error on failure instead of the whole thing crashing? > > that???s not possible, once you segfault, you segfault. > > > Or is the only way to do that have the called thing running as a separate > > app (e.g. via OSSubProcess) and communicate via pipes or sockets? > > that???s not done. > no idea how much effort is required to implement, but I imagine is not > trivial. > I have not tried it with FFI calls, but maybe this will do what you want: RemoteTask do: [ 2 + 2 ] ==> 4 Instead of [ 2 + 2 ] use some block containing your FFI calls. It works in Pharo. To get RemoteTask, load OSProcess and CommandShell. You also need Fuel, but I think that is in the image by default. An explanation of RemoteTask is at http://wiki.squeak.org/squeak/6176. You are right, it was not trivial to implement ;-) HTH, Dave
Re: [Pharo-users] Smalltalk on Stack Overflow Developers Survey 2017
On Sun, Mar 26, 2017 at 11:43 PM, Stephan Eggermont wrote: > On 26/03/17 04:16, Pierce Ng wrote: >> >> On Sat, Mar 25, 2017 at 07:56:03PM +0100, Stephan Eggermont wrote: >>> >>> On 25/03/17 18:29, serge.stinckw...@gmail.com wrote: Nice ! But do you have a way to automatize this process ? ;-) >>> >>> How difficult can it be? We did it 18 years ago in java & delphi :) >> >> >> I was going to answer 'Hadoop!', then went to SO and saw your (Stephan's) >> meta-comment on moderators who closed a question on big data in Smalltalk. >> Heh. bah! what could *small*talk possibly have to do with *big* data. go gossip somewhere else! cheers -ben ;)
Re: [Pharo-users] using UFFI in non-crashing way
On Sun, Mar 26, 2017 at 05:45:04PM +0200, Esteban Lorenzano wrote: > > > On 26 Mar 2017, at 15:40, Peter Uhnak wrote: > > > > Hi, > > > > is it possible to use UFFI and avoid crashing the image when the called > > code segfaults? > > > > In other words, can I somehow wrap the call and throw in-image > > Exception/Error on failure instead of the whole thing crashing? > > that’s not possible, once you segfault, you segfault. Ah, ok. > > > Or is the only way to do that have the called thing running as a separate > > app (e.g. via OSSubProcess) and communicate via pipes or sockets? > > that’s not done. > no idea how much effort is required to implement, but I imagine is not > trivial. Nono, I didn't mean making UFFI calls via socket (although that would be interesting), but rather making a C app that would make the calls, and that would provide a socket interface. (Which is what I typically do with other langs). Thanks, Peter
Re: [Pharo-users] Installing Voyage ??
Add an issue in the Voyage github repo and do a pull request to push esteban releasing a new version. On Sun, Mar 26, 2017 at 1:15 PM, Norbert Hartl wrote: > I get that same problem, too, every time I do "Software update". But never > understood the rationale of dropping a database at this point. I think we > should remove this line > > Norbert > > > Am 25.03.2017 um 22:04 schrieb Hilaire : > > > > ah yeah, I wrote an internal durty hack to get it rolling > > > > cleanUp: aRepository > > (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase] > > > > > >> Le 25/03/2017 à 21:46, Hilaire a écrit : > >> It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my > >> image, I don't remember. > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > >
Re: [Pharo-users] using UFFI in non-crashing way
Le 26/03/2017 à 19:21, Peter Uhnak a écrit : On Sun, Mar 26, 2017 at 05:45:04PM +0200, Esteban Lorenzano wrote: On 26 Mar 2017, at 15:40, Peter Uhnak wrote: Hi, is it possible to use UFFI and avoid crashing the image when the called code segfaults? In other words, can I somehow wrap the call and throw in-image Exception/Error on failure instead of the whole thing crashing? that’s not possible, once you segfault, you segfault. Ah, ok. Or is the only way to do that have the called thing running as a separate app (e.g. via OSSubProcess) and communicate via pipes or sockets? that’s not done. no idea how much effort is required to implement, but I imagine is not trivial. Nono, I didn't mean making UFFI calls via socket (although that would be interesting), but rather making a C app that would make the calls, and that would provide a socket interface. (Which is what I typically do with other langs). With UFFI and a standard way to marshall types over a socket (ASN.1 or even xml-rpc), this could be generated automatically. Of course, you may have a few performance issues, but you could have a long-lived child to avoid paying the startup time, and mmap / shared memory to lower the cost of moving memory back and forth. Thierry Thanks, Peter
Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change
Even "Date today" and "Date now" is created by DateAndTime. So, due to the DateAndTime internals, one can't persist Date instance (eg. with Fuel) and use it as exact "date/day value" for comparisons later in time (when GST changes back and forth). The same date value (one created before DST change, one created after DST change) will be different even in long run (on the DST change day - Date today in created on 1:00am will be different from Date today created on 2:00 am - weird! it's the same day!). Isn't the usage of "time" component in Date class a bug (at least in comparison #= method)? What about to redefine #= instance method in Date class (it's defined in Timespan super class now)? = comparand ^ self species = comparand species and: [ self translateToUTC = comparand translateToUTC ]. Opinions? pf > Date>>year:month:day: (respectively Date>>#starting:) is using DateAndTime to > specify the start, and DateAndTime will of course differ. > > To me it seems like someone was reusing implementation; because Date normally > shouldn't have/care about time information, and yet it subclasses from > Timespan class, which has/cares about time information. So the Date is > actually encoded in Timespan's 'starting' instVar as DateAndTime instance, > which is obviously breaking if TimeZone is applied. > > Maybe a fix (apart from not using Time in Date) would be to make sure Date's > methods use DateAndTime offset to 0? > Because even without daylight saving, if you create a Date instance in one > country, and move to different TZ it should break; so always keeping it UTC/0 > would make sense to me. > > Peter > > On Sun, Mar 26, 2017 at 10:17:14AM +0200, Petr Fischer wrote: > > Hello, > > > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) > > with this code: > > > > D1 := Date year: 2017 month: 3 day: 26. > > > > Date object is created with instvars: > > start: 2017-03-26T00:00:00+01:00 > > duration: 1:00:00:00 > > > > 2) when I create same Date instance with the same code on/after: 2017/03/26 > > (after Daylight Saving Time change): > > > > D2 := Date year: 2017 month: 3 day: 26. > > > > Date instance with this instvars returned: > > start: 2017-03-26T00:00:00+02:00 > > duration: 1:00:00:00 > > > > 3) D1 != D2 > > > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: > > 26) created before DST change is not equal with date instance (Date year: > > 2017 month: 3 day: 26) created after DST change. > > DST change breaks equality of the same date :( > > > > Is it OK? > > > > Thanks! Petr Fischer > > >
Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change
Did you check the Zn counterpart because I know that some parts are much better. But I do not have them at hand. Stef On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer wrote: > Hello, > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) > with this code: > > D1 := Date year: 2017 month: 3 day: 26. > > Date object is created with instvars: > start: 2017-03-26T00:00:00+01:00 > duration: 1:00:00:00 > > 2) when I create same Date instance with the same code on/after: > 2017/03/26 (after Daylight Saving Time change): > > D2 := Date year: 2017 month: 3 day: 26. > > Date instance with this instvars returned: > start: 2017-03-26T00:00:00+02:00 > duration: 1:00:00:00 > > 3) D1 != D2 > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: > 26) created before DST change is not equal with date instance (Date year: > 2017 month: 3 day: 26) created after DST change. > DST change breaks equality of the same date :( > > Is it OK? > > Thanks! Petr Fischer > >
Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change
> On 26 Mar 2017, at 21:56, Stephane Ducasse wrote: > > Did you check the Zn counterpart because I know that some parts are much > better. > But I do not have them at hand. You mean ZTimestamp (but it is not a part of Zinc HTTP Components). https://github.com/svenvc/ztimestamp This is an UTC, second precision timestamp without TZ info, and a number of interesting tools. However, that won't solve the issue raised. Some people think of a date as an abstract calendar date, while for others its a concrete day (my Monday is not your Monday if we are in different time zones). I don't think there is only one solution, both roles are needed/useful. Note that STON serialises Dates as -MM-DD which is what you seem to want. The ZTimezone class knows about the exact transitions, but that still does not mean that no weird things happen at the transition point, au contraire ;-) > Stef > > On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer wrote: > Hello, > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) > with this code: > > D1 := Date year: 2017 month: 3 day: 26. > > Date object is created with instvars: > start: 2017-03-26T00:00:00+01:00 > duration: 1:00:00:00 > > 2) when I create same Date instance with the same code on/after: 2017/03/26 > (after Daylight Saving Time change): > > D2 := Date year: 2017 month: 3 day: 26. > > Date instance with this instvars returned: > start: 2017-03-26T00:00:00+02:00 > duration: 1:00:00:00 > > 3) D1 != D2 > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: > 26) created before DST change is not equal with date instance (Date year: > 2017 month: 3 day: 26) created after DST change. > DST change breaks equality of the same date :( > > Is it OK? > > Thanks! Petr Fischer > >
Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux
Hi Esteban & Ben, On 26 March 2017 at 10:49, Esteban Lorenzano wrote: > >> On 26 Mar 2017, at 09:10, Alistair Grant wrote: >> I haven't used travis, but it looks like it is defining a number of >> environment variables, e.g. ARCH, FLAVOR, SRC_ARCH, HEARTBEAT. If I >> want the 32 bit linux threaded heartbeat, do I need to set these >> manually? > > no, once compiled is done (and your compilation worked). > those variables are for travis consumption, to allow use to pick the right > artifact to build, but you already did it by hand :) Thanks for pointing this out, I wouldn't have realised that the compilation succeeded. :-) On 26 March 2017 at 15:20, Ben Coman wrote: > On Sun, Mar 26, 2017 at 3:10 PM, Alistair Grant wrote: >> On 26 March 2017 at 04:09, Pierce Ng wrote: >>> On Sat, Mar 25, 2017 at 07:29:29PM +0100, Alistair Grant wrote: make[3]: *** No rule to make target '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.23.0'. >>> >>> Sorry, also >>> >>> % sudo apt-get install libssl-dev:i386 >> >> Thanks, Pierce. >> >> That gets past the previous errors, I'm now getting: >> >> ... >> Installing links > > Is there text cut from the right side of these lines. The next three > lines are repeated, but maybe there was something more to distinguish > them? Also line 5 "squeak/5.0-" seems cut off. There was text cut off from the right side of the lines. I cut-and-pasted this from the terminal, but still not sure how the text was cut, my apologies for the inconvenience. See below for "5.0-". >From my most recent build: Installing links DONE make[1]: Leaving directory '/data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/third-party' /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. make[1]: Entering directory '/data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/third-party' cp -f /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- Installing links DONE make[1]: Leaving directory '/data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/third-party' /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build The "squeak/5.0-" directory is no longer present after the build completes, however the path to the final vm is: "parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-" I agree that "5.0-" is a strange directory name, however looking at the version info produced by my vm vs. the version info produced by get.pharo.org/60+vmT, I suspect that there's something missing in my build environment. 60+vmT produces: 5.0-201702221539 Wed Feb 22 15:46:29 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] 201702221539 looks like a timestamp. Not sure why it is missing in my vm. (I assume that squeak/5.0- is renamed to pharo/5.0- in editpharoinstall.sh) >> cp -f >> /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 >> /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/***products***/phcogspurlinuxht/lib/squeak/5.0- > > Check whats under the ***products*** folder I marked above. $ ls -R pharo-vm/opensmalltalk-vm/products parts/pharo/build/pharo-vm/opensmalltalk-vm/products: phcogspurlinuxht parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht: bin lib pharo parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/bin: pharo parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib: pharo parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo: 5.0- parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-: AioPlugin JPEGReadWriter2Plugin libSDL2-2.0.so.0.4.1 libssl.so.1.0.0 vm-display-null B3DAcceleratorPlugin libcrypto.so.1.0.0 libSDL2.so pharo vm-display-X11 EventsHandlerPlugin libgit2.so libssh2.so RePlugin vm-sound-ALSA FT2Plugin libgit2.so.0.23.0 libssh2.so.1 SqueakSSL vm-sound-null InternetConfigPlugin libgit2.so.23 libssh2.so.1.0.1 SurfacePlugin vm-sound-OSS JPEGReaderPlugin libSDL2-2.0.so.0 libssl.so vm-display-fbdev > >> Installing links >> DONE >> /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build >> can't find PharoV50.sources > > PharoV50.sources [1] needs to sit next to the VM or Image files to be found. > "can't find" it, is a standard messag
Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux
On Mon, Mar 27, 2017 at 5:25 AM, Alistair Grant wrote:
> Trying to use the VM produces:
>
> THERE_BE_DRAGONS_HERE
> Your VM is too old for this image. Please download the latest VM.
> 26 March 2017 10:54:36.099174 pm
Last night I built the 64-bit pharo-vm on OSX
and then trying to run 60451-64.image gave me the same error.
I didn't have time to look into it.
cheers -ben
>
> VM: unix - i686 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2175
> uuid: eb79e804-a80b-4ad3-bd19-9c60a24a14f1 Mar 26 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2174 uuid:
> eefef0d3-2df8-4fe7-9f71-2aca68641ba6 Mar 26 2017
> VM: Date: Plugins:
>
> Image: Pharo6.0 [Latest update: #60447]
>
> StartupUIManager>>inform:
> Receiver: a StartupUIManager
> Arguments and temporary variables:
> arg1: 'Your VM is too old for this image. Please download the latest VM.'
> tmp1: nil
> Receiver's instance variables:
> doNotQuitOnRestart: false
> uiManager: nil
>
>
> DiskStore class(Object)>>inform:
> Receiver: DiskStore
> Arguments and temporary variables:
> arg1: 'Your VM is too old for this image. Please download the latest VM.'
> Receiver's instance variables:
> superclass: FileSystemStore
> methodDict: a MethodDictionary(#=->DiskStore>>#=
> #basenameFromEntry:->DiskStore...etc...
> format: 65537
> layout: a FixedLayout
> instanceVariables: nil
> organization: a ClassOrganization
> subclasses: {UnixStore. WindowsStore}
> name: #DiskStore
> classPool: a Dictionary(#CurrentFS->a FileSystem #Primitives->a
> FilePluginPrims...etc...
> sharedPools: nil
> environment: a SystemDictionary(lots of globals)
> category: #'FileSystem-Disk'
> traitComposition: {}
> localSelectors: nil
> ...
>
>
> The same thing happens with a V5.0 image.
>
> FYI:
>
> $ pharo.ui --version
> 5.0- Sun Mar 26 20:48:38 UTC 2017 gcc 5.4.0 [Production Spur VM]
> CoInterpreter VMMaker.oscog-eem.2175 uuid:
> eb79e804-a80b-4ad3-bd19-9c60a24a14f1 Mar 26 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2174 uuid:
> eefef0d3-2df8-4fe7-9f71-2aca68641ba6 Mar 26 2017
> VM: Date:
> Plugins:
> Linux 10b18a356b12 4.8.0-41-generic #44~16.04.1-Ubuntu SMP Fri Mar 3
> 17:11:16 UTC 2017 i686 i686 i686 GNU/Linux
> plugin path: /snap/pharo/x1/usr/bin/pharo-vm/ [default:
> /snap/pharo/x1/usr/bin/pharo-vm/]
>
>
> Given I've only just built the VM, I'm a bit surprised that it is too old. :-)
>
> I'm basically using Esteban's instructions, i.e.:
>
> $ git clone https://github.com/pharo-project/pharo-vm.git
> $ cd pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build
> $ ./mvm
>
> Once I get this working properly, hopefully I can contribute some
> documentation back that makes it easier for the next person.
>
> More hints please... :-)
>
> Thanks very much for all you assistance,
> Alistair
Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change
Thanks for tips to external Date/Time implementation. I implemented custom #= and #< methods in Date class as extension to solve my issue. It's sad a little, that base Date/Time classes is not enough and external libs existed. pf > > > On 26 Mar 2017, at 21:56, Stephane Ducasse wrote: > > > > Did you check the Zn counterpart because I know that some parts are much > > better. > > But I do not have them at hand. > > You mean ZTimestamp (but it is not a part of Zinc HTTP Components). > > https://github.com/svenvc/ztimestamp > > This is an UTC, second precision timestamp without TZ info, and a number of > interesting tools. > > However, that won't solve the issue raised. Some people think of a date as an > abstract calendar date, while for others its a concrete day (my Monday is not > your Monday if we are in different time zones). > > I don't think there is only one solution, both roles are needed/useful. > > Note that STON serialises Dates as -MM-DD which is what you seem to want. > > The ZTimezone class knows about the exact transitions, but that still does > not mean that no weird things happen at the transition point, au contraire ;-) > > > Stef > > > > On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer wrote: > > Hello, > > > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) > > with this code: > > > > D1 := Date year: 2017 month: 3 day: 26. > > > > Date object is created with instvars: > > start: 2017-03-26T00:00:00+01:00 > > duration: 1:00:00:00 > > > > 2) when I create same Date instance with the same code on/after: 2017/03/26 > > (after Daylight Saving Time change): > > > > D2 := Date year: 2017 month: 3 day: 26. > > > > Date instance with this instvars returned: > > start: 2017-03-26T00:00:00+02:00 > > duration: 1:00:00:00 > > > > 3) D1 != D2 > > > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: > > 26) created before DST change is not equal with date instance (Date year: > > 2017 month: 3 day: 26) created after DST change. > > DST change breaks equality of the same date :( > > > > Is it OK? > > > > Thanks! Petr Fischer > > > > > >
Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux
On 27 March 2017 at 01:37, Ben Coman wrote: > On Mon, Mar 27, 2017 at 5:25 AM, Alistair Grant wrote: >> Trying to use the VM produces: >> >> THERE_BE_DRAGONS_HERE >> Your VM is too old for this image. Please download the latest VM. >> 26 March 2017 10:54:36.099174 pm > > Last night I built the 64-bit pharo-vm on OSX > and then trying to run 60451-64.image gave me the same error. > I didn't have time to look into it. Thanks for the confirmation. In my case it's caused by the VM failing to report the VM, Date and Plugin information (which can be seen from the --version information I supplied previously), which probably also ties back to the "5.0-" directory. So hopefully once that is sorted, it will all magically work. Thanks again, Alistair
