Seaside XD image packaging woes

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

Last night while trying to sleep, I had what I thought was a great idea, save the XD image without reducing/packaging it.  I would have to find a way to start it in the right spot but I think I can do that.  I remember a while back someone (I think from Instantiations) posted a way to run a script when an image starts.  I tried it at the time and it worked but I haven't used it since then.

Well my great idea is not so great as the size of the XD image before adding my code is larger than the development image and even larger after I load my code.  What's up with that?

Anyway, I'm going to give this a try and will report back what happens.

Lou

Thanks for the reply.  Yes, I'm using the latest ECAP on the Raspberry Pi.  I will be glad to take anything you would like to share that may help.

As for my experiment to go without reduction/packaging, I have figured out that I should be able to use an abt.cnf file to start the program where I want it started.  So far I'm still having problems without the whole ECAP folder structure.  I will keep at it for a while.

A side question.  I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?  What do I do with EMSRV?  Is it the same version?  If not, can I use just the new version for both versions of VA Smalltalk?

Thanks, Lou 

On Tuesday, July 3, 2018 at 12:59:57 PM UTC-4, marianopeck wrote:

On Tue, Jul 3, 2018 at 12:52 PM Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="TVHpo-s0CwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:

Hi Everyone,

Hi Louis

 

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

I agree that dealing with packaging rules is not a walk in the park. It's also true that most developers usually let that till the end (as we used to do with testing years ago) rather than doing it in a continues fashion. My personal ideal recommendation is to have packaging as part of your CI infrastructure.

 

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

I completely agree with you. That's why for 9.1 we tried to improve this situation:

1) We added packaging rules to Seaside, Grease, Sst, and some other internal libraries. The idea of this was not only to get Seaside working on XD but also to remove as much warnings as possible from the reduction step. 

2) We created a Seaside Hello World  with a PackagingInstruction subclass. The idea was to have a simple example that you can package out of the box and that you can start from that one rather than from scratch. 

This effort was too close to release date and 1) implied changing and adding several apps/maps. Because of this, we decided to delay it for 9.2.

So.... for sure we would like to get this into first ECAP of 9.2, but if you want at least I can share you the hello world + the packaging instruction subclass. You would still get lots of warnings in the reduce step (because you won't have 1)) but it might give you a working image and something from which to start your own. 

 

You are also using the latest ECAP for this Seaside app?

Let me know,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="TVHpo-s0CwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mp...@...

"I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?"

- Yes

"What do I do with EMSRV?"

- Nothing...the protocol has stayed stable so you can still use 8.6.3

"f not, can I use just the new version for both versions of VA Smalltalk?"

- Yes...32 or 64-bit emsrv server.  Doesn't matter since it's a socket comm with a protocol 

-- Seth

On Tuesday, July 3, 2018 at 2:02:28 PM UTC-4, Louis LaBrunda wrote:

Hi Mariano,

Thanks for the reply.  Yes, I'm using the latest ECAP on the Raspberry Pi.  I will be glad to take anything you would like to share that may help.

As for my experiment to go without reduction/packaging, I have figured out that I should be able to use an abt.cnf file to start the program where I want it started.  So far I'm still having problems without the whole ECAP folder structure.  I will keep at it for a while.

A side question.  I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?  What do I do with EMSRV?  Is it the same version?  If not, can I use just the new version for both versions of VA Smalltalk?

Thanks, Lou 

On Tuesday, July 3, 2018 at 12:59:57 PM UTC-4, marianopeck wrote:

On Tue, Jul 3, 2018 at 12:52 PM Louis LaBrunda <[hidden email]> wrote:

Hi Everyone,

Hi Louis

 

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

I agree that dealing with packaging rules is not a walk in the park. It's also true that most developers usually let that till the end (as we used to do with testing years ago) rather than doing it in a continues fashion. My personal ideal recommendation is to have packaging as part of your CI infrastructure.

 

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

I completely agree with you. That's why for 9.1 we tried to improve this situation:

1) We added packaging rules to Seaside, Grease, Sst, and some other internal libraries. The idea of this was not only to get Seaside working on XD but also to remove as much warnings as possible from the reduction step. 

2) We created a Seaside Hello World  with a PackagingInstruction subclass. The idea was to have a simple example that you can package out of the box and that you can start from that one rather than from scratch. 

This effort was too close to release date and 1) implied changing and adding several apps/maps. Because of this, we decided to delay it for 9.2.

So.... for sure we would like to get this into first ECAP of 9.2, but if you want at least I can share you the hello world + the packaging instruction subclass. You would still get lots of warnings in the reduce step (because you won't have 1)) but it might give you a working image and something from which to start your own. 

 

You are also using the latest ECAP for this Seaside app?

Let me know,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

Thanks for the answers.

Will I be able to build Raspberry Pi images in a 32 bit Windows VA Smalltalk 9.1?  A 64 bit?

All of my VA Smalltalk programs run in less than 200 MBs most around 20 MBs, any reason to go to 64 bits?

Lou


On Tuesday, July 3, 2018 at 2:22:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

"I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?"

- Yes

"What do I do with EMSRV?"

- Nothing...the protocol has stayed stable so you can still use 8.6.3

"f not, can I use just the new version for both versions of VA Smalltalk?"

- Yes...32 or 64-bit emsrv server.  Doesn't matter since it's a socket comm with a protocol 

-- Seth

On Tuesday, July 3, 2018 at 2:02:28 PM UTC-4, Louis LaBrunda wrote:

Hi Mariano,

Thanks for the reply.  Yes, I'm using the latest ECAP on the Raspberry Pi.  I will be glad to take anything you would like to share that may help.

As for my experiment to go without reduction/packaging, I have figured out that I should be able to use an abt.cnf file to start the program where I want it started.  So far I'm still having problems without the whole ECAP folder structure.  I will keep at it for a while.

A side question.  I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?  What do I do with EMSRV?  Is it the same version?  If not, can I use just the new version for both versions of VA Smalltalk?

Thanks, Lou 

On Tuesday, July 3, 2018 at 12:59:57 PM UTC-4, marianopeck wrote:

On Tue, Jul 3, 2018 at 12:52 PM Louis LaBrunda <[hidden email]> wrote:

Hi Everyone,

Hi Louis

 

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

I agree that dealing with packaging rules is not a walk in the park. It's also true that most developers usually let that till the end (as we used to do with testing years ago) rather than doing it in a continues fashion. My personal ideal recommendation is to have packaging as part of your CI infrastructure.

 

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

I completely agree with you. That's why for 9.1 we tried to improve this situation:

1) We added packaging rules to Seaside, Grease, Sst, and some other internal libraries. The idea of this was not only to get Seaside working on XD but also to remove as much warnings as possible from the reduction step. 

2) We created a Seaside Hello World  with a PackagingInstruction subclass. The idea was to have a simple example that you can package out of the box and that you can start from that one rather than from scratch. 

This effort was too close to release date and 1) implied changing and adding several apps/maps. Because of this, we decided to delay it for 9.2.

So.... for sure we would like to get this into first ECAP of 9.2, but if you want at least I can share you the hello world + the packaging instruction subclass. You would still get lots of warnings in the reduce step (because you won't have 1)) but it might give you a working image and something from which to start your own. 

 

You are also using the latest ECAP for this Seaside app?

Let me know,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

Sure.

From the image/IC/packaging view...there is no difference between a Raspberry PI (Raspian or Linux flavor) smalltalk image and the standard Linux/AIX/Solaris smalltalk image.  It's the same image.

The only difference between the 2 are the virtual machine, emsrv/client libs, and any other supporting dlls.

They have all been compiled to run on the ARM processor of the PI.

That's why in the ECAP RaspberryPi folder there are no images...it's using the Linux ones from one folder up.

Nothing changes elsewhere...it's just Linux.  The 'System architecture' will report ARM though...so you can tell from Smalltalk if you are running on ARM.

Save an image on Linux x86 and then go launch it on the PI.

Create a packaged image for Linux x86 and then go run it on the PI.

- The chip is 64-bit I believe, but there are hardly any 32-bit PI operating systems.  It's mostly not necessary for that device.
- Also, I would first need to put a 64-bit OS on the PI and compile the vm...which I have not done (and am unlikely to do in the near future)

- Not for the PI...no.

- In general, the reason to go 64-bit has less to do with 64-bit capability, and more to do with getting os and library support (32-bit OS Linux distributions are less and less common and so is library support).

- Seth

On Tuesday, July 3, 2018 at 2:33:20 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for the answers.

Will I be able to build Raspberry Pi images in a 32 bit Windows VA Smalltalk 9.1?  A 64 bit?

All of my VA Smalltalk programs run in less than 200 MBs most around 20 MBs, any reason to go to 64 bits?

Lou


On Tuesday, July 3, 2018 at 2:22:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

"I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?"

- Yes

"What do I do with EMSRV?"

- Nothing...the protocol has stayed stable so you can still use 8.6.3

"f not, can I use just the new version for both versions of VA Smalltalk?"

- Yes...32 or 64-bit emsrv server.  Doesn't matter since it's a socket comm with a protocol 

-- Seth

On Tuesday, July 3, 2018 at 2:02:28 PM UTC-4, Louis LaBrunda wrote:

Hi Mariano,

Thanks for the reply.  Yes, I'm using the latest ECAP on the Raspberry Pi.  I will be glad to take anything you would like to share that may help.

As for my experiment to go without reduction/packaging, I have figured out that I should be able to use an abt.cnf file to start the program where I want it started.  So far I'm still having problems without the whole ECAP folder structure.  I will keep at it for a while.

A side question.  I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?  What do I do with EMSRV?  Is it the same version?  If not, can I use just the new version for both versions of VA Smalltalk?

Thanks, Lou 

On Tuesday, July 3, 2018 at 12:59:57 PM UTC-4, marianopeck wrote:

On Tue, Jul 3, 2018 at 12:52 PM Louis LaBrunda <[hidden email]> wrote:

Hi Everyone,

Hi Louis

 

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

I agree that dealing with packaging rules is not a walk in the park. It's also true that most developers usually let that till the end (as we used to do with testing years ago) rather than doing it in a continues fashion. My personal ideal recommendation is to have packaging as part of your CI infrastructure.

 

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

I completely agree with you. That's why for 9.1 we tried to improve this situation:

1) We added packaging rules to Seaside, Grease, Sst, and some other internal libraries. The idea of this was not only to get Seaside working on XD but also to remove as much warnings as possible from the reduction step. 

2) We created a Seaside Hello World  with a PackagingInstruction subclass. The idea was to have a simple example that you can package out of the box and that you can start from that one rather than from scratch. 

This effort was too close to release date and 1) implied changing and adding several apps/maps. Because of this, we decided to delay it for 9.2.

So.... for sure we would like to get this into first ECAP of 9.2, but if you want at least I can share you the hello world + the packaging instruction subclass. You would still get lots of warnings in the reduce step (because you won't have 1)) but it might give you a working image and something from which to start your own. 

 

You are also using the latest ECAP for this Seaside app?

Let me know,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

Thanks for the answers.  See where I messed up a question or two below.

On Tuesday, July 3, 2018 at 2:48:44 PM UTC-4, Seth Berman wrote:

Hi Lou,

"Will I be able to build Raspberry Pi images in a 32 bit Windows VA Smalltalk 9.1?"

Sure.

From the image/IC/packaging view...there is no difference between a Raspberry PI (Raspian or Linux flavor) smalltalk image and the standard Linux/AIX/Solaris smalltalk image.  It's the same image.

The only difference between the 2 are the virtual machine, emsrv/client libs, and any other supporting dlls.

They have all been compiled to run on the ARM processor of the PI.

That's why in the ECAP RaspberryPi folder there are no images...it's using the Linux ones from one folder up.

Nothing changes elsewhere...it's just Linux.  The 'System architecture' will report ARM though...so you can tell from Smalltalk if you are running on ARM.

Save an image on Linux x86 and then go launch it on the PI.

Create a packaged image for Linux x86 and then go run it on the PI.

64-bit?

- The chip is 64-bit I believe, but there are hardly any 64-bit PI operating systems.  It's mostly not necessary for that device.
- Also, I would first need to put a 64-bit OS on the PI and compile the vm...which I have not done (and am unlikely to do in the near future)

"Any reason to go to 64 bits?"

- Not for the PI...no.

- In general, the reason to go 64-bit has less to do with 64-bit capability, and more to do with getting os and library support (32-bit OS Linux distributions are less and less common and so is library support).

- Seth

On Tuesday, July 3, 2018 at 2:33:20 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for the answers.

Will I be able to build Raspberry Pi images in a 32 bit Windows VA Smalltalk 9.1?  A 64 bit?

All of my VA Smalltalk programs run in less than 200 MBs most around 20 MBs, any reason to go to 64 bits?

Lou


On Tuesday, July 3, 2018 at 2:22:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

"I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?"

- Yes

"What do I do with EMSRV?"

- Nothing...the protocol has stayed stable so you can still use 8.6.3

"f not, can I use just the new version for both versions of VA Smalltalk?"

- Yes...32 or 64-bit emsrv server.  Doesn't matter since it's a socket comm with a protocol 

-- Seth

On Tuesday, July 3, 2018 at 2:02:28 PM UTC-4, Louis LaBrunda wrote:

Hi Mariano,

Thanks for the reply.  Yes, I'm using the latest ECAP on the Raspberry Pi.  I will be glad to take anything you would like to share that may help.

As for my experiment to go without reduction/packaging, I have figured out that I should be able to use an abt.cnf file to start the program where I want it started.  So far I'm still having problems without the whole ECAP folder structure.  I will keep at it for a while.

A side question.  I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?  What do I do with EMSRV?  Is it the same version?  If not, can I use just the new version for both versions of VA Smalltalk?

Thanks, Lou 

On Tuesday, July 3, 2018 at 12:59:57 PM UTC-4, marianopeck wrote:

On Tue, Jul 3, 2018 at 12:52 PM Louis LaBrunda <[hidden email]> wrote:

Hi Everyone,

Hi Louis

 

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

I agree that dealing with packaging rules is not a walk in the park. It's also true that most developers usually let that till the end (as we used to do with testing years ago) rather than doing it in a continues fashion. My personal ideal recommendation is to have packaging as part of your CI infrastructure.

 

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

I completely agree with you. That's why for 9.1 we tried to improve this situation:

1) We added packaging rules to Seaside, Grease, Sst, and some other internal libraries. The idea of this was not only to get Seaside working on XD but also to remove as much warnings as possible from the reduction step. 

2) We created a Seaside Hello World  with a PackagingInstruction subclass. The idea was to have a simple example that you can package out of the box and that you can start from that one rather than from scratch. 

This effort was too close to release date and 1) implied changing and adding several apps/maps. Because of this, we decided to delay it for 9.2.

So.... for sure we would like to get this into first ECAP of 9.2, but if you want at least I can share you the hello world + the packaging instruction subclass. You would still get lots of warnings in the reduce step (because you won't have 1)) but it might give you a working image and something from which to start your own. 

 

You are also using the latest ECAP for this Seaside app?

Let me know,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

To package a 32-bit application...you install a 32-bit version of VAST

To package a 64-bit application...you install a 64-bit version of VAST

See here in our FAQ for more information about "Why 64-bit?"
You will see that memory is just one aspect of why 64-bit is important.

- Seth

On Tuesday, July 3, 2018 at 3:41:25 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for the answers.  See where I messed up a question or two below.

On Tuesday, July 3, 2018 at 2:48:44 PM UTC-4, Seth Berman wrote:

Hi Lou,

"Will I be able to build Raspberry Pi images in a 32 bit Windows VA Smalltalk 9.1?"

Sure.

From the image/IC/packaging view...there is no difference between a Raspberry PI (Raspian or Linux flavor) smalltalk image and the standard Linux/AIX/Solaris smalltalk image.  It's the same image.

The only difference between the 2 are the virtual machine, emsrv/client libs, and any other supporting dlls.

They have all been compiled to run on the ARM processor of the PI.

That's why in the ECAP RaspberryPi folder there are no images...it's using the Linux ones from one folder up.

Nothing changes elsewhere...it's just Linux.  The 'System architecture' will report ARM though...so you can tell from Smalltalk if you are running on ARM.

Save an image on Linux x86 and then go launch it on the PI.

Create a packaged image for Linux x86 and then go run it on the PI.

64-bit?

- The chip is 64-bit I believe, but there are hardly any 64-bit PI operating systems.  It's mostly not necessary for that device.
- Also, I would first need to put a 64-bit OS on the PI and compile the vm...which I have not done (and am unlikely to do in the near future)

Here I meant to be asking about Windows or at least my Windows install of 9.1.  Does one choose to install a 32 bit or 64 bit v9.1 or is there just one 32/64 bit version that lets you choose 32 or 64 bit output images during packaging?

 

"Any reason to go to 64 bits?"

- Not for the PI...no.

- In general, the reason to go 64-bit has less to do with 64-bit capability, and more to do with getting os and library support (32-bit OS Linux distributions are less and less common and so is library support).

Again, I should have been clear that I was asking about the Windows world.  Until the Raspbian OS can't get 32 bit libraries, 32 bits is good there.  My programs tend to have working sets well under the limits of 32 bit code.  Is there some other reason to go 64 bits and is there any disadvantage?  I guess 64 bit images might be larger and objects in memory would be larger because all the pointers are twice as big but that may not be much of a price to pay given todays architectures and the price of memory.  If the added cost is small one might just go to 64 bits and be done with it.

Lou

 

- Seth

On Tuesday, July 3, 2018 at 2:33:20 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for the answers.

Will I be able to build Raspberry Pi images in a 32 bit Windows VA Smalltalk 9.1?  A 64 bit?

All of my VA Smalltalk programs run in less than 200 MBs most around 20 MBs, any reason to go to 64 bits?

Lou


On Tuesday, July 3, 2018 at 2:22:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

"I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?"

- Yes

"What do I do with EMSRV?"

- Nothing...the protocol has stayed stable so you can still use 8.6.3

"f not, can I use just the new version for both versions of VA Smalltalk?"

- Yes...32 or 64-bit emsrv server.  Doesn't matter since it's a socket comm with a protocol 

-- Seth

On Tuesday, July 3, 2018 at 2:02:28 PM UTC-4, Louis LaBrunda wrote:

Hi Mariano,

Thanks for the reply.  Yes, I'm using the latest ECAP on the Raspberry Pi.  I will be glad to take anything you would like to share that may help.

As for my experiment to go without reduction/packaging, I have figured out that I should be able to use an abt.cnf file to start the program where I want it started.  So far I'm still having problems without the whole ECAP folder structure.  I will keep at it for a while.

A side question.  I have VA Smalltalk 8.6.3 installed on Windows.  Can I keep it installed as is and add v9.1 when it comes out for real?  What do I do with EMSRV?  Is it the same version?  If not, can I use just the new version for both versions of VA Smalltalk?

Thanks, Lou 

On Tuesday, July 3, 2018 at 12:59:57 PM UTC-4, marianopeck wrote:

On Tue, Jul 3, 2018 at 12:52 PM Louis LaBrunda <[hidden email]> wrote:

Hi Everyone,

Hi Louis

 

I spent the better part of yesterday trying to package my Seaside program that controls the GPIO pins on a Raspberry Pi.  I'm still working on it.  I was reluctant to start because on Windows I have all this kind of packaging automated and I had forgotten how to do it.  How to do it came back fairly quickly.  I now think that I had a mental block on how to do it because it is such a pain in the ass.

XD image packaging is always somewhat of a pain to set up because we don't do the setup part very often.  We forget to make sure our prerequisites are right and that our configuration maps are complete and in the right order.  But to be fair that's our own fault and it really doesn't take much to set things right and the prerequisite area of the "Application Manager" is a big help.

I agree that dealing with packaging rules is not a walk in the park. It's also true that most developers usually let that till the end (as we used to do with testing years ago) rather than doing it in a continues fashion. My personal ideal recommendation is to have packaging as part of your CI infrastructure.

 

The trouble come in the reduction phase, especially with Seaside.  I don't know why but it seems to be way too aggressive.  It reduces the hell out of the image only to have the "find errors phase" complain about missing methods that exist because their class was auto-magically removed by reduction.  I have fixed this before when packaging Seaside programs and it takes forever.  You have to add a whole bunch of packaging instructions to tell the packager not to reduce most if not all of Seaside (which there are many apps).  I for one would love to have an option that would not try to reduce any of the Seaside apps without me having to name them all.  I'm willing to have larger packaged images (within reason) if I don't have to go crazy making them.

I completely agree with you. That's why for 9.1 we tried to improve this situation:

1) We added packaging rules to Seaside, Grease, Sst, and some other internal libraries. The idea of this was not only to get Seaside working on XD but also to remove as much warnings as possible from the reduction step. 

2) We created a Seaside Hello World  with a PackagingInstruction subclass. The idea was to have a simple example that you can package out of the box and that you can start from that one rather than from scratch. 

This effort was too close to release date and 1) implied changing and adding several apps/maps. Because of this, we decided to delay it for 9.2.

So.... for sure we would like to get this into first ECAP of 9.2, but if you want at least I can share you the hello world + the packaging instruction subclass. You would still get lots of warnings in the reduce step (because you won't have 1)) but it might give you a working image and something from which to start your own. 

 

You are also using the latest ECAP for this Seaside app?

Let me know,

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

Well, sort of both.  I have done most of the development on Windows (VA Smalltalk 8.6.3) and prefer this because it is what I am use to and my Windows machine is faster and everything is set up the way I like, bigger screen, better keyboard, etc.  But in order to test the Raspberry GPIO interface code and then the Seaside/Raspberry program, I have loaded things on to the Raspberry.  I did the testing in the development environment.  Now, I would like to make a packaged image and install it on a Raspberry Pi Zero W, to see how that goes.  Eventually I want to put it on an old Raspberry Pi 1 and replace the Squeak version that currently controls my friends garage doors.

I may be a little bit ahead of the curve here.  I think I have to wait for the real v9.1 and install that on Windows.  It may not have the advanced Seaside packaging support but it should still be better than doing it on the Raspberry.

Lou

One more question.  Can 32/64 bit object dumper/loader data (files) be read by the other image/system?  If data dumped from a 32 bit system be read by a 64 bit system and vice versa?

Lou

" If data dumped from a 32 bit system be read by a 64 bit system and vice versa?"

64-bit vm can read/write 32-bit object graphs.

64-bit vm writes 32-bit object graph by default.
32-bit can only read/write 32-bit object graphs.

See more information in comments of
EswDumpingStrategy>>compatibilityMode:

On Tuesday, July 3, 2018 at 5:47:02 PM UTC-4, Louis LaBrunda wrote:

Sorry, Everybody for splitting this thread into two parts.

One more question.  Can 32/64 bit object dumper/loader data (files) be read by the other image/system?  If data dumped from a 32 bit system be read by a 64 bit system and vice versa?

Lou

Mariano,

this caught my attention:

That is an excellent point, we've helped a few projects get rid of their holy images and the rainmaker who is called packager. CI is key to speedig up the process, especially in maintenance of legacy code where you sometimes have to ship fixes in minutes rather than hours...

...but may I be a bit destructive here: it is not too hard to automate the "normal" packaging process in VAST. Not a walk in the park but possible.

In case of XD packaging, hwever, you end up in a really ugly nightmare trying to do so. I know a few people found ways to do all that stuff like load a Map into the passive image without the Packaged Image Browser, but this is really hard.

So maybe Instantiations could add a new item to their to-do list: add support for integration with CI infrastructure. Start by providing simpler and better documented APIs for the steps needed in packaging as well as XD packaging.

 Joachim

Hi Joachim and Mariano,

 

If Joachim is referring to what I think he is, I have done this.  Once you have good packaging instructions, I have classes that extend the process to automate running most if not all of it.  I have even added menu items to the popup menu that appears when you right click on an object in an app in the VisualAge Organizer window.  One for headless images and one for GUI images.  The menu items are only enabled if the class is setup to be packaged in this way.  I am willing to share and I think there is an old post of mine in this forum that describers much of the process.  Unfortunately, the classes are very, very much tied to what I what done with the packaged, including renaming, zipping and coping things around on my disk.  It may take quite some refactoring to separate things.  If you are interested, maybe after v9.1 is out the door we can talk about it.

Lou

Lou,

I've done that for "normal" packaging of a GUI application: menu item in the Transcript, loads the code and packages. Also, we've triggered builds using jenkins, including running sUnit tests. So it is perfectly doable, even if the APIs are undocumented.

However, I miserably failed trying something similar for XD Packaging. How to create a passive image, how to load into it etc. ? I finally gave up...

I'd love to see code snippets that help me get further with this because we mainly XD package these days...

Joachim

Hi Louis,

I will describe the scenario which we believe is the most comfortable for your case. That is, develop on Windows and then make a XD reduced image for deploying on Linux (Raspbian in your case). This was tested with latest 9.1 ECAP and 32 bits (we still need a few changes for 64 bits). 

-------------------

1) On Windows,  load Server Workbench and Seaside on a development image. You can script it:

 #(

 ) do: [:each | (EmConfigurationMap editionsFor: each) 

first loadWithRequiredMaps 

]. 

1.1) Apply this patch that will be available in next ECAP or Release and its our internal case 63626.

2) Import and load latest version of SeasideHelloWorld and SeasideHelloWorldPackagingInstructionsApp. The former represents your domain-specific Seaside app (in this case a Hello World). The latter is one possible/easy way to package a Seaside application. It serves as an example and as starting point. This is mostly the only piece you may want to look deeper to adapt it for your own usage.

3) From the main menu, "XD" -> "New Image". Select the feature "Communications - TCP/IP". 

4) Once inside the XD image, open configuration map browser and "Load with Required Maps" the map "zz.Server.AbtSstSeasideFeature"

5) In XD image, go to "Tools" -> "Browse Application Additions", and load latest version of SeasideHelloWorld.  This step simulates what it would be loading your own Seaside app.

6) In XD go to "Tools" -> "Browse Packaged Images" and select the tab "Instructions In Database". You should see SeasideHelloWorldPackagingInstructionsApp. Double click to expand the tree and select AbtXDHelloWorldSeasidePackagingInstructions.

7) Follow the packaging workflow until the end. You should get a seasideHelloWorld.icx, SEASIDEHELLOWORLD.SNP, spusage.es, assocs.es and symbols.es all written. 

8) Move all those files from your Windows to your Linux machine. 

9) On Linux, be sure to have latest ECAP too and start XD image from a console like this (update bold paths and any other info you might need):

10) Open a web browser on http://localhost:8888/helloworld 

 

I think the resulting behavior is very nice. You can develop on Windows (those that prefer that) and deploy a reduced image in Linux (with full Seaside the .icx is 7MB).

Please, let me know if that works. Unfortunately, I am leaving for vacations on Saturday so I may not be able to be very responsive.