DateAndTime users' questionnaire
Locked
DateAndTime users' questionnaire
 
|
If you use DateAndTime in your GemStone application, we at GemTalk would
very much appreciate your feedback on the questions below. At customer request, we're working on a SmallDateAndTime class for GemStone -- a "Special" (immediate) version of DateAndTime that relates to DateAndTime similarly to the relationship between SmallInteger and LargeInteger. For customers with many persistent DateAndTime instances, this should improve both space and time performance. There are design tradeoffs in resolution, range, printing, etc., and it will help us make better decisions if we know how DateAndTime is being used now. (1) Which of the following messages do you use to create DateAndTime instances? * DateAndTime now * DateAndTime nowWithScale: * DateAndTime fromString: * DateAndTime year:day:hour* or year:month:day:hour* * Other protocol (2) Do you need DateAndTimes with resolution finer than a microsecond? (3) What is your year range of DateAndTime; do you need or use DateAndTimes more than 5/10/50 years into the future (or the past)? (4) How do you handle DateAndTime printing? (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or added your own methods to DateAndTime or DateAndTimeANSI? If this is general functionality that could be useful to include in the base, please let us know. (6) DateAndTime instances would need to be immutable, to be interoperable with SmallDateAndTime. If you are using methods that do update a DateAndTime, such as offset: or beRounded, does your code expect the receiver to be modified? _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
On Fri, Jun 19, 2020 at 8:46 PM Martin McClure via GemStone-Smalltalk
<[hidden email]> wrote: > > If you use DateAndTime in your GemStone application, we at GemTalk would > very much appreciate your feedback on the questions below. > > At customer request, we're working on a SmallDateAndTime class for > GemStone -- a "Special" (immediate) version of DateAndTime that relates > to DateAndTime similarly to the relationship between SmallInteger and > LargeInteger. For customers with many persistent DateAndTime instances, > this should improve both space and time performance. > > There are design tradeoffs in resolution, range, printing, etc., and it > will help us make better decisions if we know how DateAndTime is being > used now. Although I don't use GS these days, I want to participate. DateAndTime has always been an "expensive" object, and having it as an immediate object is something I always wanted. > (1) Which of the following messages do you use to create DateAndTime > instances? > * DateAndTime now > * DateAndTime fromString: Also fromUNIXTime: or equivalent. > (2) Do you need DateAndTimes with resolution finer than a microsecond? Not even so. Seconds is fine. > (3) What is your year range of DateAndTime; do you need or use > DateAndTimes more than 5/10/50 years into the future (or the past)? +/- 10 years I'd say. > (4) How do you handle DateAndTime printing? Depends. Using it's ISO representation or a locale printer. > (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or > added your own methods to DateAndTime or DateAndTimeANSI? If this is > general functionality that could be useful to include in the base, > please let us know. No. > (6) DateAndTime instances would need to be immutable, to be > interoperable with SmallDateAndTime. If you are using methods that do > update a DateAndTime, such as offset: or beRounded, does your code > expect the receiver to be modified? I always treated DateAndTime as immutable, except when I was optimizing something because I didn't have immediate DateAndTime! Regards! _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
In reply to this post by Gemstone/S mailing list
I'm excited for this change, it will make a huge performance difference having dates as immediates. I had done this in tuning in application code where most beneficial. It would persist an immediate integer that was seconds, ms, or ns from an epoch datetime. Replication to gbs was then a very efficiently of course as cache costs were skipped. The slot contained the integer and accessor methods made it look like a datetime was stored. The accessor methods used DateTime extensions (like maybe #ms:fromEpoch:, #seconds:fromEpoch: #msFromEpoch:, and #secondsFromEpoch:) to do conversions between integer and DateTime instances according to the epoch and granularity the accessors had consistently specified for the slot in both objectspaces (gbs and gs). This allowed for incremental application tuning and epoch control most efficient for the attribute needs. The epoch that I selected for most slots was probably 1/1/2000, but it might have also been more recent if the attribute didn't need older dates stored efficiently. Sorry, I don't recall what epoch and granularity was generally most useful for most attributes. If polymorphism can be assumed then you might as well pick an epoch in the near future and dates forward will become more efficient. Paul Baumann On Fri, Jun 19, 2020, 7:46 PM Martin McClure via GemStone-Smalltalk <[hidden email]> wrote: If you use DateAndTime in your GemStone application, we at GemTalk would _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
(1) Which of the following messages do you use to create DateAndTime instances? * DateAndTime now * DateAndTime nowWithScale: * DateAndTime fromString: * DateAndTime year:day:hour* or year:month:day:hour* * Other protocol DateAndTime now - almost always used a 'created' or 'changed' timestamp. DateAndTime secondsUTC:offset: - only because we use our own code to store DateAndTime values as integers (2) Do you need DateAndTimes with resolution finer than a microsecond? No. Seconds is fine. (3) What is your year range of DateAndTime; do you need or use DateAndTimes more than 5/10/50 years into the future (or the past)? No. 30 years in the past would be the oldest for us. (4) How do you handle DateAndTime printing? Use use our own displayString which outputs YYYY-MM-DD HH:MM:SS ... i.e. ISO with a space between date and time instead of a 'T' (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or added your own methods to DateAndTime or DateAndTimeANSI? If this is general functionality that could be useful to include in the base, please let us know. No. (6) DateAndTime instances would need to be immutable, to be interoperable with SmallDateAndTime. If you are using methods that do update a DateAndTime, such as offset: or beRounded, does your code expect the receiver to be modified? No. We tread DateAndTime instances as immutable. Bob Nemec KORE
On Friday, June 19, 2020, 09:36:54 p.m. EDT, Paul Baumann via GemStone-Smalltalk <[hidden email]> wrote:
I'm excited for this change, it will make a huge performance difference having dates as immediates. I had done this in tuning in application code where most beneficial. It would persist an immediate integer that was seconds, ms, or ns from an epoch datetime. Replication to gbs was then a very efficiently of course as cache costs were skipped. The slot contained the integer and accessor methods made it look like a datetime was stored. The accessor methods used DateTime extensions (like maybe #ms:fromEpoch:, #seconds:fromEpoch: #msFromEpoch:, and #secondsFromEpoch:) to do conversions between integer and DateTime instances according to the epoch and granularity the accessors had consistently specified for the slot in both objectspaces (gbs and gs). This allowed for incremental application tuning and epoch control most efficient for the attribute needs. The epoch that I selected for most slots was probably 1/1/2000, but it might have also been more recent if the attribute didn't need older dates stored efficiently. Sorry, I don't recall what epoch and granularity was generally most useful for most attributes. If polymorphism can be assumed then you might as well pick an epoch in the near future and dates forward will become more efficient. Paul Baumann On Fri, Jun 19, 2020, 7:46 PM Martin McClure via GemStone-Smalltalk <[hidden email]> wrote: If you use DateAndTime in your GemStone application, we at GemTalk would _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
In reply to this post by Gemstone/S mailing list
Hi Martin,
> (1) Which of the following messages do you use to create DateAndTime instances? > * DateAndTime now > * DateAndTime nowWithScale: > * DateAndTime fromString: > * DateAndTime year:day:hour* or year:month:day:hour* > * Other protocol All of the above (except nowWithScale:) but, more importantly also the variants with an #offset: argument (i.e. timezone support). Also: #date:time: > (2) Do you need DateAndTimes with resolution finer than a microsecond? No > (3) What is your year range of DateAndTime; do you need or use DateAndTimes more than 5/10/50 years into the future (or the past)? More than 10 years, less than 50 years (both in future and the past). In practice, up to 20 years in the past and 10 years in the future (relative to today), but the date time instances of the year 2030, created today, will still have to be the same in 2040 (and beyond) as well. > (4) How do you handle DateAndTime printing? method extensions, printing date times in various locales and export formats > (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or added your own methods to DateAndTime or DateAndTimeANSI? If this is general functionality that could be useful to include in the base, please let us know. No subclasses, but many extension methods. Perhaps some common export formats (like to javascript) are useful but others are mostly convenience methods or Pharo-compatibility methods. > (6) DateAndTime instances would need to be immutable, to be interoperable with SmallDateAndTime. If you are using methods that do update a DateAndTime, such as offset: or beRounded, does your code expect the receiver to be modified? We use the #offset: and #rounded methods, but threat them as if they would deliver copies of the original. So, yes, immutable please ;) Cheers Johan _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
In reply to this post by Gemstone/S mailing list
I was working on a Shipping operation application called IRIS2 long time ago. We canonicalized the DataTime to reduce the number of instances created that represent the same time. Our resolution is 1 minute to reduce the number of instances we need to create. Recently, while working on a Java application we also need DateTime, we represented DateTime using the format YYYYMMDDHHMMSS.mmm. This format can be represented as an Integer (64bit) in GemStone. In GemStone, if I remember correctly it does not create a new object but embedded 64 bit Integer in the object pointer. So no extra space taken. And you can implement getter and setter that can dynamically return a transient DateTime object. I used this technique in Java because we cached a lot of objects in the VM. This will save a lot of memory space. This YYYYMMDDHHMMSS.mmm representation is much more readable but at a cost of converting when you need to print them. Mang
On Friday, June 19, 2020, 06:37:06 PM PDT, Paul Baumann via GemStone-Smalltalk <[hidden email]> wrote:
I'm excited for this change, it will make a huge performance difference having dates as immediates. I had done this in tuning in application code where most beneficial. It would persist an immediate integer that was seconds, ms, or ns from an epoch datetime. Replication to gbs was then a very efficiently of course as cache costs were skipped. The slot contained the integer and accessor methods made it look like a datetime was stored. The accessor methods used DateTime extensions (like maybe #ms:fromEpoch:, #seconds:fromEpoch: #msFromEpoch:, and #secondsFromEpoch:) to do conversions between integer and DateTime instances according to the epoch and granularity the accessors had consistently specified for the slot in both objectspaces (gbs and gs). This allowed for incremental application tuning and epoch control most efficient for the attribute needs. The epoch that I selected for most slots was probably 1/1/2000, but it might have also been more recent if the attribute didn't need older dates stored efficiently. Sorry, I don't recall what epoch and granularity was generally most useful for most attributes. If polymorphism can be assumed then you might as well pick an epoch in the near future and dates forward will become more efficient. Paul Baumann On Fri, Jun 19, 2020, 7:46 PM Martin McClure via GemStone-Smalltalk <[hidden email]> wrote: If you use DateAndTime in your GemStone application, we at GemTalk would _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
Good choice Mang. YYYYMMDDHHMMSS (even with the decimal) conforms to ISO 8601 ... following the standard rarely hurts. And if I read your times in light of the standard I even know the time zone .. Z/UTC/GMT (hoping that is what you intend!) Good to hear that GemStone are looking at canonicalising date-times. When I was working with GemStone (happy days) I tended to just use >>now to make a new one, but I'd make sure to persist them as Mang does ... not least because the ISO 8601 integer approach can be moved around between systems without being messed up by various oh-so-clever date time libraries in languages, databases etc. All the best, Bruce On Wed, 24 Jun 2020 at 06:01, Wai Lun Mang via GemStone-Smalltalk <[hidden email]> wrote:
_______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
In reply to this post by Gemstone/S mailing list
Gemstone/S mailing list wrote
> If you use DateAndTime in your GemStone application, we at GemTalk would > very much appreciate your feedback on the questions below. > > At customer request, we're working on a SmallDateAndTime class for > GemStone -- a "Special" (immediate) version of DateAndTime that relates > to DateAndTime similarly to the relationship between SmallInteger and > LargeInteger. For customers with many persistent DateAndTime instances, > this should improve both space and time performance. > > There are design tradeoffs in resolution, range, printing, etc., and it > will help us make better decisions if we know how DateAndTime is being > used now. > > (1) Which of the following messages do you use to create DateAndTime > instances? > * DateAndTime now > * DateAndTime nowWithScale: > * DateAndTime fromString: > * DateAndTime year:day:hour* or year:month:day:hour* > * Other protocol I use the DateTime class as it seemed faster for instantiation and comparison. But in that class of the methods you mention I use #now #year:month:day:hour* #fromString: Other instantiation methods I;ve added are date:in: epoch fromDate: fromDateAndTime: fromDateTime:butIn: fromHourString: fromHourString:on: fromJSTime: fromSeconds: fromString:madeInTimeZone: fromUnixTime: tomorrow unixEpoch year:day:hour:minute:second:offset: year:day:hour:minute:second:timeZone: year:month:day: year:month:day:hour:minute:second: year:month:day:hour:minute:second:offset: year:month:day:hour:minute:second:timeZone: yesterday > (2) Do you need DateAndTimes with resolution finer than a microsecond? No > > (3) What is your year range of DateAndTime; do you need or use > DateAndTimes more than 5/10/50 years into the future (or the past)? January 2004 to now plus some years into the future. > (4) How do you handle DateAndTime printing? I made a bunch of #print... convenience methods. e.g printShortDate printShortTime printHM printMDY ..... > (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or > added your own methods to DateAndTime or DateAndTimeANSI? If this is > general functionality that could be useful to include in the base, > please let us know. 150 extension methods on DateTime & about 100 on DateAndTime. I've no idea which of them I use most but I think a lot of them. Mostly printing and comparison/conversion convenience methods. > (6) DateAndTime instances would need to be immutable, to be > interoperable with SmallDateAndTime. If you are using methods that do > update a DateAndTime, such as offset: or beRounded, does your code > expect the receiver to be modified? I always make new ones. > _______________________________________________ > GemStone-Smalltalk mailing list > GemStone-Smalltalk@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk -- Sent from: http://forum.world.st/Gemstone-S-f1461796.html _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
In reply to this post by Gemstone/S mailing list
Hi Mang,
In the Java program, with the integer representation, how did you handle Daylight savings transitions when doing comparisons or instantiating objects? Thanks Paul Gemstone/S mailing list wrote > I was working on a Shipping operation application called IRIS2 long time > ago. We canonicalized the DataTime to reduce the number of instances > created that represent the same time. Our resolution is 1 minute to > reduce the number of instances we need to create. > Recently, while working on a Java application we also need DateTime, we > represented DateTime using the format YYYYMMDDHHMMSS.mmm. This format can > be represented as an Integer (64bit) in GemStone. In GemStone, if I > remember correctly it does not create a new object but embedded 64 bit > Integer in the object pointer. So no extra space taken. And you can > implement getter and setter that can dynamically return a transient > DateTime object. I used this technique in Java because we cached a lot of > objects in the VM. This will save a lot of memory space. > This YYYYMMDDHHMMSS.mmm representation is much more readable but at a cost > of converting when you need to print them. > Mang > On Friday, June 19, 2020, 06:37:06 PM PDT, Paul Baumann via > GemStone-Smalltalk < > gemstone-smalltalk@.gemtalksystems > > wrote: > > I'm excited for this change, it will make a huge performance difference > having dates as immediates. > I had done this in tuning in application code where most beneficial. It > would persist an immediate integer that was seconds, ms, or ns from an > epoch datetime. Replication to gbs was then a very efficiently of course > as cache costs were skipped. The slot contained the integer and accessor > methods made it look like a datetime was stored. The accessor methods used > DateTime extensions (like maybe #ms:fromEpoch:, #seconds:fromEpoch: > #msFromEpoch:, and #secondsFromEpoch:) to do conversions between integer > and DateTime instances according to the epoch and granularity the > accessors had consistently specified for the slot in both objectspaces > (gbs and gs). This allowed for incremental application tuning and epoch > control most efficient for the attribute needs. > > The epoch that I selected for most slots was probably 1/1/2000, but it > might have also been more recent if the attribute didn't need older dates > stored efficiently. Sorry, I don't recall what epoch and granularity was > generally most useful for most attributes. If polymorphism can be assumed > then you might as well pick an epoch in the near future and dates forward > will become more efficient. > Paul Baumann > > > On Fri, Jun 19, 2020, 7:46 PM Martin McClure via GemStone-Smalltalk < > gemstone-smalltalk@.gemtalksystems > > wrote: > > If you use DateAndTime in your GemStone application, we at GemTalk would > very much appreciate your feedback on the questions below. > > At customer request, we're working on a SmallDateAndTime class for > GemStone -- a "Special" (immediate) version of DateAndTime that relates > to DateAndTime similarly to the relationship between SmallInteger and > LargeInteger. For customers with many persistent DateAndTime instances, > this should improve both space and time performance. > > There are design tradeoffs in resolution, range, printing, etc., and it > will help us make better decisions if we know how DateAndTime is being > used now. > > (1) Which of the following messages do you use to create DateAndTime > instances? > * DateAndTime now > * DateAndTime nowWithScale: > * DateAndTime fromString: > * DateAndTime year:day:hour* or year:month:day:hour* > * Other protocol > > (2) Do you need DateAndTimes with resolution finer than a microsecond? > > (3) What is your year range of DateAndTime; do you need or use > DateAndTimes more than 5/10/50 years into the future (or the past)? > > (4) How do you handle DateAndTime printing? > > (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or > added your own methods to DateAndTime or DateAndTimeANSI? If this is > general functionality that could be useful to include in the base, > please let us know. > > (6) DateAndTime instances would need to be immutable, to be > interoperable with SmallDateAndTime. If you are using methods that do > update a DateAndTime, such as offset: or beRounded, does your code > expect the receiver to be modified? > _______________________________________________ > GemStone-Smalltalk mailing list > GemStone-Smalltalk@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk > > _______________________________________________ > GemStone-Smalltalk mailing list > GemStone-Smalltalk@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk > > _______________________________________________ > GemStone-Smalltalk mailing list > GemStone-Smalltalk@.gemtalksystems > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk -- Sent from: http://forum.world.st/Gemstone-S-f1461796.html _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Re: DateAndTime users' questionnaire
|
|
In the Java program, we did not use integer because it is not big enough. We use Long to represent because Java does not have 64bit Integer. We stored the time in utc time zone. So comparison is easy and can be convert to any timezone when needed. Mang
On Thursday, June 25, 2020, 01:13:35 PM PDT, Paul DeBruicker via GemStone-Smalltalk <[hidden email]> wrote:
Hi Mang, In the Java program, with the integer representation, how did you handle Daylight savings transitions when doing comparisons or instantiating objects? Thanks Paul Gemstone/S mailing list wrote > I was working on a Shipping operation application called IRIS2 long time > ago. We canonicalized the DataTime to reduce the number of instances > created that represent the same time. Our resolution is 1 minute to > reduce the number of instances we need to create. > Recently, while working on a Java application we also need DateTime, we > represented DateTime using the format YYYYMMDDHHMMSS.mmm. This format can > be represented as an Integer (64bit) in GemStone. In GemStone, if I > remember correctly it does not create a new object but embedded 64 bit > Integer in the object pointer. So no extra space taken. And you can > implement getter and setter that can dynamically return a transient > DateTime object. I used this technique in Java because we cached a lot of > objects in the VM. This will save a lot of memory space. > This YYYYMMDDHHMMSS.mmm representation is much more readable but at a cost > of converting when you need to print them. > Mang > On Friday, June 19, 2020, 06:37:06 PM PDT, Paul Baumann via > GemStone-Smalltalk < > [hidden email] > > wrote: > > I'm excited for this change, it will make a huge performance difference > having dates as immediates. > I had done this in tuning in application code where most beneficial. It > would persist an immediate integer that was seconds, ms, or ns from an > epoch datetime. Replication to gbs was then a very efficiently of course > as cache costs were skipped. The slot contained the integer and accessor > methods made it look like a datetime was stored. The accessor methods used > DateTime extensions (like maybe #ms:fromEpoch:, #seconds:fromEpoch: > #msFromEpoch:, and #secondsFromEpoch:) to do conversions between integer > and DateTime instances according to the epoch and granularity the > accessors had consistently specified for the slot in both objectspaces > (gbs and gs). This allowed for incremental application tuning and epoch > control most efficient for the attribute needs. > > The epoch that I selected for most slots was probably 1/1/2000, but it > might have also been more recent if the attribute didn't need older dates > stored efficiently. Sorry, I don't recall what epoch and granularity was > generally most useful for most attributes. If polymorphism can be assumed > then you might as well pick an epoch in the near future and dates forward > will become more efficient. > Paul Baumann > > > On Fri, Jun 19, 2020, 7:46 PM Martin McClure via GemStone-Smalltalk < > [hidden email] > > wrote: > > If you use DateAndTime in your GemStone application, we at GemTalk would > very much appreciate your feedback on the questions below. > > At customer request, we're working on a SmallDateAndTime class for > GemStone -- a "Special" (immediate) version of DateAndTime that relates > to DateAndTime similarly to the relationship between SmallInteger and > LargeInteger. For customers with many persistent DateAndTime instances, > this should improve both space and time performance. > > There are design tradeoffs in resolution, range, printing, etc., and it > will help us make better decisions if we know how DateAndTime is being > used now. > > (1) Which of the following messages do you use to create DateAndTime > instances? > * DateAndTime now > * DateAndTime nowWithScale: > * DateAndTime fromString: > * DateAndTime year:day:hour* or year:month:day:hour* > * Other protocol > > (2) Do you need DateAndTimes with resolution finer than a microsecond? > > (3) What is your year range of DateAndTime; do you need or use > DateAndTimes more than 5/10/50 years into the future (or the past)? > > (4) How do you handle DateAndTime printing? > > (5) Have you created a subclass of DateAndTime or DateAndTimeANSI, or > added your own methods to DateAndTime or DateAndTimeANSI? If this is > general functionality that could be useful to include in the base, > please let us know. > > (6) DateAndTime instances would need to be immutable, to be > interoperable with SmallDateAndTime. If you are using methods that do > update a DateAndTime, such as offset: or beRounded, does your code > expect the receiver to be modified? > _______________________________________________ > GemStone-Smalltalk mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk > > _______________________________________________ > GemStone-Smalltalk mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk > > _______________________________________________ > GemStone-Smalltalk mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk -- Sent from: http://forum.world.st/Gemstone-S-f1461796.html _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk _______________________________________________ GemStone-Smalltalk mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
«
Return to Gemstone/S
|
1 view|%1 views
| Free forum by Nabble | Edit this page |