Scratch packaging

 (Google is acting weird. I am having great difficulty replying to you message.)

>> Any ideas?

As far as I know, the packager packages what's loaded in the image. That would include unpublished changes.

Hi Richard,

I use config files for packaging and I'm pretty sure it won't use un-versioned apps but I will try to test that theory soon.

Lou

On Sunday, October 18, 2020 at 4:15:15 PM UTC-4 Richard Sargent wrote:

 (Google is acting weird. I am having great difficulty replying to you message.)

>> Any ideas?

As far as I know, the packager packages what's loaded in the image. That would include unpublished changes.

Lou,

as far as I remember, the packager only warns you about unversioned classes. It does package whatever is in the image.

Nevertheless, I guess ypur main problem will be loading all the scratches and open editions into your passive image for cross-packaging (or do you package a GUI app?). I am quite sure this is a lot more work and error prone than developing some routine for versioning all open editions.

I am a big fan of the "Version" "Include Subapplications and Clases" menu in the Applications Manager (I dismiss the Organizer immediately when I start with a fresh image) for that purpose. Tha way you can also use the "Release all latest" menu item in the config map browser to make your stuff loadable in one click or automated in an XD image...

So instead of making unversioned stuff loadable in some defined combination (and thus somehow replication Applications and Config Maps), I'd suggest looking for ways to version/release fast.

... or do you see any problems in the number of versions such an approach produces? I'd be surprised if that was the case and would like to learn something new here.

Joachim

[hidden email] schrieb am Sonntag, 18. Oktober 2020 um 22:26:15 UTC+2:

Hi Richard,

I use config files for packaging and I'm pretty sure it won't use un-versioned apps but I will try to test that theory soon.

Lou

On Sunday, October 18, 2020 at 4:15:15 PM UTC-4 Richard Sargent wrote:

 (Google is acting weird. I am having great difficulty replying to you message.)

>> Any ideas?

As far as I know, the packager packages what's loaded in the image. That would include unpublished changes.

Hi Joachim , 

I agree with everything you say and am also a big fan of the "Version".  I do package XD images and use config maps for both my GUI and headless apps (this one is headless) and have automated the process.  I have added popup menu items that when I right click on the "main" part allow me to run the packaging process.  As I said, this program is headless and is "controlled" through Seaside presenting web pages that allow the changing of setting and even manually turning pins on/off.  I can debug the Seaside portion from the development in Windows.  That all goes well.

Where I have problems, is with the Raspberry hardware specific code that often requires one tiny change at a time.  I then have to version/package and copy the image to the Raspberry, to test the change.  None of that really takes very long.  It just rubs me the wrong way that I have to "open" an app, make the small change (often just adding debug log messages and not an attempt at a fix) and version again.  I know those versions are not final.  This isn't really a problem, it is just to me very annoying.  That's why I titled this post "Scratch packaging", like scratch editions.

Lou

P.S.  The current problem I am chasing is with code that does something when a GPIO pin turns on.  The pin turns on unexpectedly.  I'm close to solving it but I am in the loop of making a very small change/versioning/packaging/copying/testing.  The versioning step seems to me to be unnecessary.

On Monday, October 19, 2020 at 1:46:15 AM UTC-4 [hidden email] wrote:

Lou,

as far as I remember, the packager only warns you about unversioned classes. It does package whatever is in the image.

Nevertheless, I guess ypur main problem will be loading all the scratches and open editions into your passive image for cross-packaging (or do you package a GUI app?). I am quite sure this is a lot more work and error prone than developing some routine for versioning all open editions.

I am a big fan of the "Version" "Include Subapplications and Clases" menu in the Applications Manager (I dismiss the Organizer immediately when I start with a fresh image) for that purpose. Tha way you can also use the "Release all latest" menu item in the config map browser to make your stuff loadable in one click or automated in an XD image...

So instead of making unversioned stuff loadable in some defined combination (and thus somehow replication Applications and Config Maps), I'd suggest looking for ways to version/release fast.

... or do you see any problems in the number of versions such an approach produces? I'd be surprised if that was the case and would like to learn something new here.

Joachim

[hidden email] schrieb am Sonntag, 18. Oktober 2020 um 22:26:15 UTC+2:

Hi Richard,

I use config files for packaging and I'm pretty sure it won't use un-versioned apps but I will try to test that theory soon.

Lou

On Sunday, October 18, 2020 at 4:15:15 PM UTC-4 Richard Sargent wrote:

 (Google is acting weird. I am having great difficulty replying to you message.)

>> Any ideas?

As far as I know, the packager packages what's loaded in the image. That would include unpublished changes.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/ed5b99cb-f45d-4157-9c2b-b41144528cbcn%40googlegroups.com.

Greetings all,

Some suggestions:

1) If you package something that throws an error or a Halt, then you can use the remote debugger. I paste at the end of this email, an answer I gave to someone else some weeks ago. Basically, as long as you have an exception and you open the debugger, you can then modify whatever you want. 

2) pigpiod allows REMOTE gpio access. Therefore, you can run VAST on a full blown Linux in your desktop machine, specify the IP of the PI and then make a remote GPIO. That way, you are running a development image in your desktop fast Linux, making changes, all while using the remote GPIO. See this post: https://dev.to/martinezpeck/remote-controlling-raspberry-pis-from-across-the-world-with-smalltalk-35nc

3) You can include the compiler in the XD image (the image will be bigger, of course), and make a Seaside text area where you can paste code and then add a "Do It" button. I did that years ago for a customer application. That won't help you too much with compiling methods etc (although you can still do it programatically), but at least to execute simple "do its"

4) Buy a faster Pi (like the Pi 4) that you use to run the full blow VAST and once everything is working there, you move into the Pi Zero. 

Hope this helps, 

===========

Sorry for the delay but this was gonna be a long email and our support channel is quite busy these days. 

The short answer is yes: you can use both strategies for your project (this is not IoT / ARM / Raspberry Pi) specific and we even have customers using this for many years (this feature is in the product at least since 1997). 

If I were you, before thinking how to integrate this into you project, I would start with a fresh 9.2.2 image and the Seaside Traffic Light example. That code is even shipped VAST so you can re-watch and follow the exact steps I did in the IoT demo [1] as well as at Smalltalks 2019 [2]. I recommend watching Smalltalks one if you didn't (the presentation at ESUG 2019 wasn't recorded...). I have also written a blog post [3] that will likely be of help. 

In addition to that, we have Instantiations official documentation with steps by steps instructions to use both strategies. I would read the whole "Packaging a Smalltalk image" chapter [4] and the pay special attention to the examples [5] and [6].

Once you are able to package those examples and be able to use the stack dump and the remote debugger, I would then take a look at the code that supports that. For this, the easiest way is to browse the code in your passive image where you have loaded those features. I would look at the classes AbtInteractiveDebugStartUp and AbtStackDumpStartUp. You can see what those startUp classes do and then you could even do something similar outside of the StartUp class if that's what you want. 

If you look at the code, you will see that the remote debugger, if there is an error, it fallbacks and uses the stack dump. And the stack dump, if fails, fallbacks to walkback. Something I would do for a production system is that no matter how I debug the error, I would *always* ALSO dump into a walkback. This is just in case you can't debug the binary later because of whatever reason, you are sure you at least have the walkback. In other words, I wouldn't REPLACE the walkback, but just potentially ADD the stack dump. 

One final comment...all the example you will see are using XD packaging and headless images. This would be different with fat client / desktop applications. I think the stack dump should work fairly easily and we can improve it if necessary. But the remote debugger would be much more complicated to make it work in that scenario. 

I guess with all this information you have a lot to chew on. But keep me posted of your progress. 

Best regards,

Mariano

[1] https://youtu.be/wCw0ZLStDzA

[2] https://youtu.be/u2AVD_-7E8k

[3] https://dev.to/martinezpeck/it-s-2019-stop-reading-text-and-start-debugging-2460

[4] https://www.instantiations.com/docs/922/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sv/server97.html

[5] https://www.instantiations.com/docs/922/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sv/server99-sngl-ex.html 

[6] https://www.instantiations.com/docs/922/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sv/server99-sngl-ex3.html

 =====

On Mon, Oct 19, 2020 at 9:06 AM Louis LaBrunda <[hidden email]> wrote:

Hi Joachim , 

I agree with everything you say and am also a big fan of the "Version".  I do package XD images and use config maps for both my GUI and headless apps (this one is headless) and have automated the process.  I have added popup menu items that when I right click on the "main" part allow me to run the packaging process.  As I said, this program is headless and is "controlled" through Seaside presenting web pages that allow the changing of setting and even manually turning pins on/off.  I can debug the Seaside portion from the development in Windows.  That all goes well.

Where I have problems, is with the Raspberry hardware specific code that often requires one tiny change at a time.  I then have to version/package and copy the image to the Raspberry, to test the change.  None of that really takes very long.  It just rubs me the wrong way that I have to "open" an app, make the small change (often just adding debug log messages and not an attempt at a fix) and version again.  I know those versions are not final.  This isn't really a problem, it is just to me very annoying.  That's why I titled this post "Scratch packaging", like scratch editions.

Lou

P.S.  The current problem I am chasing is with code that does something when a GPIO pin turns on.  The pin turns on unexpectedly.  I'm close to solving it but I am in the loop of making a very small change/versioning/packaging/copying/testing.  The versioning step seems to me to be unnecessary.

On Monday, October 19, 2020 at 1:46:15 AM UTC-4 [hidden email] wrote:

Lou,

as far as I remember, the packager only warns you about unversioned classes. It does package whatever is in the image.

Nevertheless, I guess ypur main problem will be loading all the scratches and open editions into your passive image for cross-packaging (or do you package a GUI app?). I am quite sure this is a lot more work and error prone than developing some routine for versioning all open editions.

I am a big fan of the "Version" "Include Subapplications and Clases" menu in the Applications Manager (I dismiss the Organizer immediately when I start with a fresh image) for that purpose. Tha way you can also use the "Release all latest" menu item in the config map browser to make your stuff loadable in one click or automated in an XD image...

So instead of making unversioned stuff loadable in some defined combination (and thus somehow replication Applications and Config Maps), I'd suggest looking for ways to version/release fast.

... or do you see any problems in the number of versions such an approach produces? I'd be surprised if that was the case and would like to learn something new here.

Joachim

[hidden email] schrieb am Sonntag, 18. Oktober 2020 um 22:26:15 UTC+2:

Hi Richard,

I use config files for packaging and I'm pretty sure it won't use un-versioned apps but I will try to test that theory soon.

Lou

On Sunday, October 18, 2020 at 4:15:15 PM UTC-4 Richard Sargent wrote:

 (Google is acting weird. I am having great difficulty replying to you message.)

>> Any ideas?

As far as I know, the packager packages what's loaded in the image. That would include unpublished changes.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/ed5b99cb-f45d-4157-9c2b-b41144528cbcn%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/