Include binary version of compiler for Raspberry Pi?

[Jim Gregory]

I've lately been using a Raspberry Pi 2 and Raspberry Pi 3 for my JAL development environment and have been very happy with it. JAL code compiles relatively quickly using the compiler, the Vim editor has syntax highlighting for JAL, I can program most chips that use low-voltage programming directly from the Pi's GPIO ports very quickly using Darren Broad's Pickle ICSP software (https://wiki.kewl.org/dokuwiki/projects:pickle), and I can easily read and write to the serial port of the PIC without an adapter using the Pi's serial port pins.

The biggest challenge has been getting the compiler set up.  JALLIB includes neither an ARM-compatible binary nor the source code for JAL, so I have to compile it from Kyle's source code and make some changes to get it to compile. FWIW, the changes that are required are:

1. remove '-Werror' from one of the options in the Makefile.inc, and
2. add a 'bin' directory to the source code tree at the same level as the 'src' directory

Would there be enough demand by users to include an ARM-compatible binary with JALLIB, or at least a version of the source code that might compiled a bit more easily for the Pi?

-Jim

[Rob Hamerling]

Hi Jim,

On 06/12/2016 12:28 PM, Jim Gregory wrote:
> I've lately been using a Raspberry Pi 2 and Raspberry Pi 3 for my JAL
> development environment and have been very happy with it. JAL code
> compiles relatively quickly using the compiler, the Vim editor has
> syntax highlighting for JAL, I can program most chips that use
> low-voltage programming directly from the Pi's GPIO ports very quickly
> using Darren Broad's Pickle ICSP software
> (https://wiki.kewl.org/dokuwiki/projects:pickle), and I can easily
> read and write to the serial port of the PIC without an adapter using
> the Pi's serial port pins.

I have a project for RPi with PICs as slave(s). I control the RPi from
my PC over the network (VNC) and after first quick reading I didn't see
a big advantage of compiling and programming on the RPI. But after some
thought I do see advantages/opportunities now!

>
> The biggest challenge has been getting the compiler set up. JALLIB
> includes neither an ARM-compatible binary nor the source code for JAL,
> so I have to compile it from Kyle's source code and make some changes
> to get it to compile.

I have been building the compiler from the sources without problems:
- for eComStation (OS/2) using Watcom C/C++
- to obtain a 64-bits Linux executable.

> FWIW, the changes that are required are:
>
> 1. remove '-Werror' from one of the options in the Makefile.inc, and
> 2. add a 'bin' directory to the source code tree at the same level as
> the 'src' directory

For the 64-bits Linux version I had similar issues (and added the -O2
option).
For eComStation I used the Watcom make utility and my own makefiles.

>
> Would there be enough demand by users to include an ARM-compatible
> binary with JALLIB, or at least a version of the source code that
> might compiled a bit more easily for the Pi?

What is 'enough demand'?
I think it is good to add an RPi executable to Jallib, and maybe also
the ICSP facility.

Regards, Rob.

--
*Rob H*amerling - http://www.robh.nl

[Matthew Schinkel]

I don't see how this will get into the release package. Who will be compiling this every time there is a new release?

I think it may be ok to make a directory in the tools dir for Jalv2 compiled for other systems. Documentation is good as well.

Matt.

[Jim Gregory]

I'm assuming the only time it would need to be recompiled is when Kyle releases a new version of the compiler, not each new release of jallib.  If that is correct, then I'd be willing to compile it (since I'm going to have to do it for myself anyway :) ), but only if it doesn't add an extra burden for you.

As for as the directory structure goes, are you proposing to leave the 'mainstream' Windows, OS X, and Linux x86 binaries in the jalv2/compiler directory as they are now, and put the others (Raspberry Pi, eComStation, etc.) in the tools directory? That seems a bit unintuitive to me, since as a new user, I'd expected to find all the compiled versions in the compiler directory.

-Jim

[Matthew Schinkel]

Hi Jim,

You would only need to compile it when there is a new version of the compiler available. You may upload it to github at tools/compiler/jalv2_pi_2.4q5/

What file name will you use? "jalv2pi"?

A small text doc on how to compile it would be nice as well.

If it's on Github, i'll be able to find it when I create the next package. I'll likely only add it to the package if the version on github is the most recent version of the compiler. Obviously we don't want to use an out of date compiler.

It would be a good contribution.

Thanks,

Matt.

[Rob Hamerling]

Hi Matt, Jim,

On 06/16/2016 05:01 AM, Matthew Schinkel wrote:
>
> You would only need to compile it when there is a new version of the
> compiler available. You may upload it to github at
> tools/compiler/jalv2_pi_2.4q5/

I agree with Jim that all compiler executables (thus also those not
originally distributed by Kyle) better be together in the same
directory. Why separate the variants now an RPi version comes up while
the one for eComStation is there for ages and also the 64-bits Linux
version is there for some time?

BTW. Talking about variants...
I don't think anybody is interested in the eComStation anymore, even not
me since I switched almost completely to Linux. So if nobody protests
against the disappearance of this variant I'll not build and upload it
new versions anymore.
And also: there was never a question before about who will build a new
eComStation variant.
I'm still prepared to build a new 64-bits Linux variant when appropriate.

[Matthew Schinkel]

Hi Guys,

I forgot there are other "out of date" compilers in the compiler directory. To me, this seems odd. The directory gets messy and I could see someone using one, not knowing they are using a old version since it came in a new jallib package. I think only the Kyle provided compilers should be directly in the compiler directory. If anyone wishes to use a variant, they can easily copy into /compiler/

Do you think we should have the variants in for example /compiler/jalv2_pi_2.4q5/ ? They would be included in the package, and there would be no question as to what version it is, how old it is, or what system it is for.

Look at \compiler\jalv2osx. I see it is for OSX operating system, but what version of jalv2 is it? How was it compiled and when? Is it compatible with current jallib libraries and samples?

Matt.

[Rob Hamerling]

Hi Matt,

On 06/17/2016 02:23 AM, Matthew Schinkel wrote:
> I forgot there are other "out of date" compilers in the compiler
> directory. To me, this seems odd. The directory gets messy and I could
> see someone using one, not knowing they are using a old version since
> it came in a new jallib package. I think only the Kyle provided
> compilers should be directly in the compiler directory.

OK, I can agree with this.

> If anyone wishes to use a variant, they can easily copy into /compiler/

When the name of the 'extra' executables reflex the destination OS and
compiler version it seems to me that one additional subdirectory of
jallib/compiler/ would be sufficient.

>
> Do you think we should have the variants in for example
> /compiler/jalv2_pi_2.4q5/ ? They would be included in the package, and
> there would be no question as to what version it is, how old it is, or
> what system it is for.

Good idea. An accompanying readme file with info about version and
destination-OS(-version) and how the variant was built or could be
re-built seems appropriate.
But only variants of the current version should be in the distribution
packages, older versions can always be downloaded separately from Github.

>
> Look at \compiler\jalv2osx. I see it is for OSX operating system, but
> what version of jalv2 is it? How was it compiled and when? Is it
> compatible with current jallib libraries and samples?

I have no OSX here, but looking in the executable I read Jalv24q2. Good
reason to not distribute it any more.

When there is agreement about the directory structure for additional
compiler executables I'll move 'my' variants.

[Matthew Schinkel]

Ok, so lets go a head and fix this.

Is there anything anyone wants from the current /compiler/ directory? I'm going to remove it all so we can start fresh. I'll upload the current compiler.

You may upload your new compiled version to a folder in /compiler/, I'll leave it there. For directory naming, go ahead with something like /compiler/jalv24q5_osname/

Matt.

[Jim Gregory]

I just created a pull request that includes the binary of the compiler (v 2.4q5) for the Raspberry Pi and similar single board computers, plus instructions on how to compile the compiler for it and other ARM-based boards.

-Jim
--
Jim Gregory
Bikes At Work Inc. www.bikesatwork.com
129 Washington Ave, Ames, IA 50010 515-233-6120

----- Matthew Schinkel <mattsc...@hotmail.com> wrote:-----

> --
> You received this message because you are subscribed to a topic in the Google Groups "jallib" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallib/QlijhpgUkkU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jallib+un...@googlegroups.com.
> To post to this group, send email to jal...@googlegroups.com.
> Visit this group at https://groups.google.com/group/jallib.
> For more options, visit https://groups.google.com/d/optout.

[Matt Schinkel]

Thanks Jim

This is much better since it came with instructions on how to compile :)

Sent from my iPhone

> You received this message because you are subscribed to the Google Groups "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

[Rob Hamerling]

On 06/18/2016 10:59 PM, Jim Gregory wrote:
> I just created a pull request that includes the binary of the compiler (v 2.4q5) for the Raspberry Pi and similar single board computers, plus instructions on how to compile the compiler for it and other ARM-based boards.
>

A pull request may be the formal way to contribute, but this seems to me
much more complicated than necessary. And (as far as I understand the
process) it requires time and effort of someone else to merge the
additions into the repository. In Jallib all contributors were always
'peers', no hierarchy. Why not take the responsibility and simply add
the files to the repository like we have done for so many years? Nothing
happens to the packaging as long as these files are not added to
TORELEASE, and since you have most likely tested your contributions you
may as well add these to TORELEASE.

Another disadvantage of this 'indirect' way of contributing is that the
additions don't show up when browsing Github. At least I cannot find 'm,
but that may be caused by my short-sightedness ;-)

[Jim Gregory]

I guess the main reason I did the pull request was because I don't have commit access to the repository, and being a newbie to this project, didn't see any other way of doing what Matt had requested :-)

I'm by no means experienced with using Github. I just did what I thought is the right way to make a contribution to an open source software project like this. If I did this the wrong way, please let me know.

And, while it does take a bit more work on my part to start making contributions (I had to fork the repository), I now have a way to make tracked revisions to my own version of the library that Matt might (or might not) choose to accept. Plus, another new fork of jallib makes jallib look more popular, which is always a good thing ;-).

Given that using git and Github have become a defacto standard of collaboration in open source software, it seems reasonable that jallib should follow the same practices of most other software projects if it wants to stay relevant and encourage other experienced software developers to contribute.

But I'm willing to defer to what everyone else thinks is best--especially Matt, since he's ultimately the one maintaining the project.

-Jim

[Pinguino Contributor]

On Friday, June 17, 2016 at 7:43:25 PM UTC+10, RobH wrote:

>> Look at \compiler\jalv2osx. I see it is for OSX operating system, but
>> what version of jalv2 is it? How was it compiled and when? Is it
>> compatible with current jallib libraries and samples?

 

> I have no OSX here, but looking in the executable I read Jalv24q2. Good
> reason to not distribute it any more.

It was compiled by Lyle remotely on my OS X Mac Mini back when that version of the compiler was current. He didn't have access to OS X and there was a bug which prevented it compiling on OS X which he fixed.

Serendipity, I just happened to look in here for the first time in a couple of years :)

Cheers.