I do not want the entire group seeing these photos.Because some may recognize
me. Here's the link:

http://chopsocky.zoomshare.com/files/photos.htm

You're Invited to join my friends network, check my profile here:
http://harleyaaboz.zoomshare.com/files/myfriend.htm

Click here to check out my new photos!
http://coolsrider.zoomshare.com/files/newfriend.htm

You have received an important Message! Check your message here:
http://xxangix.zoomshare.com/files/msg.htm

Sexy biker babes are waiting to meet you! Check their HOT profiles here:
http://josephe.zoomshare.com/files/chicks.htm

Sexy biker babes are waiting to meet you! Check their HOT profiles here:
http://alleyops.zoomshare.com/files/chicks.htm

You're Invited to join my friends network, check my profile here:
http://vinlover.zoomshare.com/files/chicks.htm

You're Invited to join my friends network, check my profile here:
http://bidonde.zoomshare.com/files/chicks.htm

You're Invited to join my friends network, check my profile here:
http://cinderel.zoomshare.com/files/chicks.htm

I'm porting my MarkIII sample programs from Jal0.4.62 to jalv2 and I'm
having problems with the hex file output of the Jalv2 compiler.

After futzing around a bit I found that the hex file generated using the
command line : jalv2 -rickpic has both fuse and eeprom data in the hex
file that the Rick Farmer boot loader doesn't know how to deal with.

After a while I found the -no-fuse compiler option, but I still need to
have a -no-eeprom flag as well.  And while I'm thinking about it,
shouldn't the compiler know that, that boot loader doesn't do fuse or
eeprom data?

Is there some easy code changes I could make to pic.c to make it more
automagic?  (I attempted a couple of hacks that didn't work as expected
so I thought I'd ask on the list before I get too far into it.)


Thanks,

--mgross

On Mar 5, 2007, at 3:21 PM, Bert van Dam wrote:

>>>> Anyone else on the list know how to get the JAL sites ranked
>>>> higher in
>>>> Google?
>>
>> Unfortunately Wouter wasn't very inspired naming the compiler JAL.
>> Japanese Air Lines can't be beated on Google.

Actually Wouter's site is ABOVE the JAL wikipedia entry on Google, as
are two other JAL pages.

http://www.google.nl/search?q=jal  (hit 7, 8, 9)

Yes, google should know that the first 7 hits point to the same
company. Since three of them are in *japanese*, I don't really blame
them.

---
ir EE van Andel eur@... www.fiwihex.nl
Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands
tel+31-546-491106 fax+31-546-491107

On Sun, Feb 25, 2007 at 03:14:06PM -0800, William Chops Westfield wrote:
>
> >> It would be cool if there was a proper community project for Jalv2, I
> >> think a lot more development on it would happen if there was.
> >>
> IIRC, there was never much development that happened on the JALv1
> sourceforge project (or, never much productive development?  Seemed
> like a lot of churn in format/etc without much real gain?)  That
> was part of the reason that JALv2 came about...
>
> It's nice to think that by opening up a project in the "real" open
> source community, you'll wind up with lots of helpers.  But it
> doesn't seem to be particularly true.
>

Jalv0.4.xx has it hay day a few years ago.  Since then its development
has stagnated.  In a sense it became "mature" in so much as it worked
well enough for the folks involved at the time.

--mgross

>> It would be cool if there was a proper community project for Jalv2, I
>> think a lot more development on it would happen if there was.
>>
IIRC, there was never much development that happened on the JALv1
sourceforge project (or, never much productive development?  Seemed
like a lot of churn in format/etc without much real gain?)  That
was part of the reason that JALv2 came about...

It's nice to think that by opening up a project in the "real" open
source community, you'll wind up with lots of helpers.  But it
doesn't seem to be particularly true.

BillW

On 24 Feb 2007, at Sat24-14:10, Mark Gross wrote:

> I'm just starting to play with Jalv2, and the first thing I've noticed
> is that the URL for the source in almost all of the documentation
> out on
> the net point to a dead link.
>
> Once I got the source the next thing I found was that here is not
> autoconif script, and there is no make install.
>
> There is also no top level documentation stating where the jal
> include /
> library files should go.  I'm assuming there is a default search path
> for this as in the Jalv0.62 from source forge.

Jal V2 was a coup d'etat by some people. I have never installed it
and never ran it. I rely on some weird JAL features ( like raw
interrupts) that do not work in JAL v2.

Yes, there should be a nice windoze JAL environment with editors and
USB programmers support. I don't know if JAL v2 is that.

I use 4.60 every day on a large variety of OS's (FreeBSD, OS X, DOS,
XP) and I'm quite happy with it.

> Further I've found that the code is not portable to 64 bit systems.  I
> had to fix up a few printf's that where casting a pointer to an
> unsigned
> that wouldn't compile cleanly.
>
> It would be cool if there was a proper community project for Jalv2, I
> think a lot more development on it would happen if there was.
>
> I'm still just getting started so I expect that there will be more
> tidbits of things that could be fixed up.
>
> Has this topic of setting up a community development side for Jalv2
> been
> discussed yet?
Talk to Stef Mientki. He probably knows.


>
>
> Thanks,
>
> --mgross
>

Eur van Andel, eur@...

I'm just starting to play with Jalv2, and the first thing I've noticed
is that the URL for the source in almost all of the documentation out on
the net point to a dead link.

Once I got the source the next thing I found was that here is not
autoconif script, and there is no make install.

There is also no top level documentation stating where the jal include /
library files should go.  I'm assuming there is a default search path
for this as in the Jalv0.62 from source forge.

Further I've found that the code is not portable to 64 bit systems.  I
had to fix up a few printf's that where casting a pointer to an unsigned
that wouldn't compile cleanly.

It would be cool if there was a proper community project for Jalv2, I
think a lot more development on it would happen if there was.

I'm still just getting started so I expect that there will be more
tidbits of things that could be fixed up.

Has this topic of setting up a community development side for Jalv2 been
discussed yet?


Thanks,

--mgross

Hi,
I've spotted these lines in jpic.jal:

var bit pin_e0_direction at trisc : 0
var bit pin_e1_direction at trisc : 1
var bit pin_e2_direction at trisc : 2

I think they sould be:

var bit pin_e0_direction at trise : 0
var bit pin_e1_direction at trise : 1
var bit pin_e2_direction at trise : 2

A patch is attached.
Ciao,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Hi all,

Available patches in jal.sf.net:

ID  Summary
1352435 10Fxxx support
1352433 Preprocessor support
1118846 JAL 16F648 Extensions



Regards,
Javi.

On Tuesday 08 November 2005 17:53, Javier Martinez wrote:
> Hi all,
>
> > > 1. Macro's can never extend or change the real functionality /
> > > performance of the compiler. This would imply that a macro-machine
> > > should always or best be implemented as a pre-processor.
> >
> > I agree, but while on unix-like systems a pre-processor is (almost)
> > always present, on other systems (windows), it is not. I'm not interested
> > in windows personally, but someone else could be, and maybe they don't
> > want to install a third-party program.
>
>    Marco, you hit in the bulls eye. Ask in the jallist how many of them
> have a C compiler to build latest JAL sources ....
>
>    ... and now think that we're asking them to have a C preprocessor to
> daily work with JAL.

Yes, I understand.

>    As a starting position (just begin to do something), we can place
> your code as a patch of latest sources. If I recall well, SF.net have a
> special entry for this purposes.

This sounds great! Thanks.

In the meantime I'll try to come to a more integrated solution.
I'll keep you posted.

Cheers,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Hi all,

> > 1. Macro's can never extend or change the real functionality /
> > performance of the compiler. This would imply that a macro-machine
> > should always or best be implemented as a pre-processor.
>
> I agree, but while on unix-like systems a pre-processor is (almost) always
> present, on other systems (windows), it is not. I'm not interested in windows
> personally, but someone else could be, and maybe they don't want to install a
> third-party program.

    Marco, you hit in the bulls eye. Ask in the jallist how many of them
have a C compiler to build latest JAL sources ....

    ... and now think that we're asking them to have a C preprocessor to
daily work with JAL.

    As a starting position (just begin to do something), we can place
your code as a patch of latest sources. If I recall well, SF.net have a
special entry for this purposes.


    Waiting your comments.



Regards,
Javi.

On Monday 07 November 2005 19:40, Stef Mientki wrote:
>
> hello Marco, Javi,
>
> As a non-C-programmer, I cann't understand the full extend /
> consequences of this C-isch macro implementation,
> but here a few remarks:
>
> 1. Macro's can never extend or change the real functionality /
> performance of the compiler. This would imply that a macro-machine
> should always or best be implemented as a pre-processor.

I agree, but while on unix-like systems a pre-processor is (almost) always
present, on other systems (windows), it is not. I'm not interested in windows
personally, but someone else could be, and maybe they don't want to install a
third-party program.

>
> 2. As I showed in JALcc, it's very well possible to create a
> pre-processor which is capable of perfoming complex macro actions, while
> still holding 100% compatibility with "standard JAL", see
>    http://oase.uci.kun.nl/~mientki/pic/jalcc/help/jalcc_macro.html
> <http://oase.uci.kun.nl/%7Emientki/pic/jalcc/help/jalcc_macro.html>
> If you look at the block "Inline Macro,IO-pin, about the end of the
> first page, you can see how this is implemented.

my extension to JAL is 100% compatible with "standard JAL" too, but the
problem is the other way round: code that uses macros is not understood by
plain JAL.

I've a couple of ideas regarding direct implementation of macros in JAL, I'll
see in the next few days if they are viable.

Cheers,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Javier Martinez wrote:

>Hi Marco,
>
>
>
>>Yes, but if someone doesn't need it, he can just ignore it.
>>
>>One possible solution could be to selective enable the preprocessor support
>>when running the "configure" script, if called with an "--enable-cpp" switch.
>>What do you think about this?
>>
>>
>
>   Yes, but what about sharing code? These macro functions will make JAL
>"other" language (JAL-cpp vs JAL), that is you'll not able to share code
>with other "not-cpp" jallians. Should be nice to find a solution
>affordable for all, rather than for a few ones.
>
>
>
>
hello Marco, Javi,

As a non-C-programmer, I cann't understand the full extend /
consequences of this C-isch macro implementation,
but here a few remarks:

1. Macro's can never extend or change the real functionality /
performance of the compiler. This would imply that a macro-machine
should always or best be implemented as a pre-processor.

2. As I showed in JALcc, it's very well possible to create a
pre-processor which is capable of perfoming complex macro actions, while
still holding 100% compatibility with "standard JAL", see
    http://oase.uci.kun.nl/~mientki/pic/jalcc/help/jalcc_macro.html
<http://oase.uci.kun.nl/%7Emientki/pic/jalcc/help/jalcc_macro.html>
If you look at the block "Inline Macro,IO-pin, about the end of the
first page, you can see how this is implemented.

3. The mentioned page describes only the build in macros in JALcc,  I've
build in  user definenable macros, but as I'm not satisfied about them,
they are not made public.

4. I'ld love to come together to get a standard definition of macros
(maybe even fully compatible with mchip-macros), which then can be
implemented in different pre-processors.

just my 2-euro-cents

cheers,
Stef

On Monday 07 November 2005 18:14, Javier Martinez wrote:
> Hi Marco,
>
> > Yes, but if someone doesn't need it, he can just ignore it.
> >
> > One possible solution could be to selective enable the preprocessor
> > support when running the "configure" script, if called with an
> > "--enable-cpp" switch. What do you think about this?
>
>    Yes, but what about sharing code? These macro functions will make JAL
> "other" language (JAL-cpp vs JAL), that is you'll not able to share code
> with other "not-cpp" jallians. Should be nice to find a solution
> affordable for all, rather than for a few ones.
>
>    And yes, the best way to enable it is in configure script.

You are right, it would impede code sharing. I think of this feature as a
"sharp knife", to be used exclusively when unavoidable, but I understand that
once users have access to a tool they tend to use it :-)

> > >    The second one, just a thought: looks like C too much, is there a
> > > way to "JALify" it? I'm thinking in something like a procedure/function
> > > syntax: "macro ( ) is ... end macro".
> >
> > This of course would be the best solution, but I suspect it would require
> > non-trivial changes to the parser. If jal could parse from a string
> > (starting from an arbitrary point in the original file, and resuming to
> > the same itpoint afterwards), it would be quite easy to do, but I doubt
> > it has this functionality.
> > I'll try to think if I can envision a solution, but someone with a deeper
> > understanding than mine of the jal parser could give better indications.
> >
> > Ciao,
> > Marco
>
>      Let's go with my first question, and then if all it's ok will find
> a solution here.

I'd go for the JAL-style solution, but I'd need some help here.

Later,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Hi Marco,

> Yes, but if someone doesn't need it, he can just ignore it.
>
> One possible solution could be to selective enable the preprocessor support
> when running the "configure" script, if called with an "--enable-cpp" switch.
> What do you think about this?

    Yes, but what about sharing code? These macro functions will make JAL
"other" language (JAL-cpp vs JAL), that is you'll not able to share code
with other "not-cpp" jallians. Should be nice to find a solution
affordable for all, rather than for a few ones.

    And yes, the best way to enable it is in configure script.




> >    The second one, just a thought: looks like C too much, is there a way
> > to "JALify" it? I'm thinking in something like a procedure/function
> > syntax: "macro ( ) is ... end macro".
>
> This of course would be the best solution, but I suspect it would require
> non-trivial changes to the parser. If jal could parse from a string (starting
> from an arbitrary point in the original file, and resuming to the same itpoint
> afterwards), it would be quite easy to do, but I doubt it has this
> functionality.
> I'll try to think if I can envision a solution, but someone with a deeper
> understanding than mine of the jal parser could give better indications.
>
> Ciao,
> Marco
>

      Let's go with my first question, and then if all it's ok will find
a solution here.



Regards,
Javi.

On Monday 07 November 2005 17:41, Javier Martinez wrote:
> Hi Marco,
>
>    Sorry, I've been busy.   ;)
>
>    Just 2 questions.
>
>    The main one: seems that needs an external C preprocessor, isn't it?
> This will be useless for 95% of JAL users, and this will give us a lot
> of problems about this.

Yes, but if someone doesn't need it, he can just ignore it.

One possible solution could be to selective enable the preprocessor support
when running the "configure" script, if called with an "--enable-cpp" switch.
What do you think about this?

>    The second one, just a thought: looks like C too much, is there a way
> to "JALify" it? I'm thinking in something like a procedure/function
> syntax: "macro ( ) is ... end macro".

This of course would be the best solution, but I suspect it would require
non-trivial changes to the parser. If jal could parse from a string (starting
from an arbitrary point in the original file, and resuming to the same point
afterwards), it would be quite easy to do, but I doubt it has this
functionality.
I'll try to think if I can envision a solution, but someone with a deeper
understanding than mine of the jal parser could give better indications.

Ciao,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Hi Marco,

    Sorry, I've been busy.   ;)

    Just 2 questions.

    The main one: seems that needs an external C preprocessor, isn't it?
This will be useless for 95% of JAL users, and this will give us a lot
of problems about this.

    The second one, just a thought: looks like C too much, is there a way
to "JALify" it? I'm thinking in something like a procedure/function
syntax: "macro ( ) is ... end macro".


    Tell me what do you think prior to do anything. Otherwise it's fine.


Regards,
Javi.


On jue, 2005-11-03 at 17:40 +0100, Marco Pantaleoni wrote:
> On Thursday 03 November 2005 16:34, Marco Pantaleoni wrote:
> >
> > If you like, I'll add a command line switch to jal to invoke automatically
> > the preprocessor, thus avoiding the two separate commands shown above.
>
> I've added that switch. Now if you run jal with the "-P" switch, it will
> invoke cpp for you.
> Compiling the example of the previous message would become:
>
>     $ jal -P silly-example.jal
>
> (jal will call cpp handling automatically the temporary file creation and
> removal).
>
> You can also specify a different "cpp" passing a command string to -P, as in:
>
>     $ jal -P/usr/local/bin/cpp silly-example.jal
>
> you can pass complex commands quoting with simple or double quotes the
> command:
>
>     $ jal -P'/usr/local/bin/cpp -funny' silly-example.jal
>
> I can't check if CVS has been updated recently (it goes in time-out right
> now), so I'm providing a patch against the CVS version without my previous
> patch. In other words, this patch supersedes the previous one.
>
> Cheers,
> Marco
>

On Thursday 03 November 2005 16:34, Marco Pantaleoni wrote:
>
> If you like, I'll add a command line switch to jal to invoke automatically
> the preprocessor, thus avoiding the two separate commands shown above.

I've added that switch. Now if you run jal with the "-P" switch, it will
invoke cpp for you.
Compiling the example of the previous message would become:

     $ jal -P silly-example.jal

(jal will call cpp handling automatically the temporary file creation and
removal).

You can also specify a different "cpp" passing a command string to -P, as in:

     $ jal -P/usr/local/bin/cpp silly-example.jal

you can pass complex commands quoting with simple or double quotes the
command:

     $ jal -P'/usr/local/bin/cpp -funny' silly-example.jal

I can't check if CVS has been updated recently (it goes in time-out right
now), so I'm providing a patch against the CVS version without my previous
patch. In other words, this patch supersedes the previous one.

Cheers,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

On Saturday 29 October 2005 17:35, Javier Martinez wrote:
> Hi Marco,

Hi Javier,
I apologize for the late answer, but I've been out of town.

>
>    Can you post a brief example in JAL?

of course.
The main use of preprocessor support in jal is to write macros, short
sequences of statements used quite often, but for which a function call would
be overkill (or too expensive in some cases). Macros should be used with
caution and moderation though, because it's easy to use them improperly or to
get burned with unforeseen "side effects" of expansion.
A short, and silly, example could be:

silly-example.jal
------------------------------------------------------------------------

include f877_4
include jlib

pragma target fuses 0x3F32

disable_a_d_functions

var bit LED1 is pin_a0
var bit LED2 is pin_a1

pin_a0_direction = output
pin_a1_direction = output

#define CYCLE_1(ms)     \
   delay_10ms( (ms) )    \
   LED1 = high           \
   LED2 = low

#define CYCLE_2(ms)     \
   delay_10ms( (ms) )    \
   LED1 = low            \
   LED2 = high

forever loop
   CYCLE_1(25)

   CYCLE_2(25)
end loop


To use this example, we have to call the preprocessor before jal.
For example:

     $ cpp silly-example.jal silly-example-expanded.jal
     $ jal silly-example-expanded.jal

This first command will process "silly-example.jal" emitting its output in
"silly-example-expanded.jal". Then with the second command we simply compile
the generated file.

If you like, I'll add a command line switch to jal to invoke automatically the
preprocessor, thus avoiding the two separate commands shown above.

Cheers,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

Hi Marco,

    Can you post a brief example in JAL?

    I'll upload changes to jal.sf.net CVS repository.


Regards,
Javi.



On vie, 2005-10-28 at 00:45 +0200, Marco Pantaleoni wrote:
> Hi,
> I've added support to jal for cpp-like preprocessors (cpp, gpp, ...).
> This essentialy allows to write macros using #define (and correctly handle
> line numbers when using #include). gpp also has some extensions to cpp that
> can be useful with jal (like user-definable comment syntax, immediate macro
> evaluation, ...).
> I attach the unified diff patch agains the cvs version of jal.
> I hope that this could be useful to someone else beside me.
>
> Cheers,
> Marco
>

Hi,
I've added support to jal for cpp-like preprocessors (cpp, gpp, ...).
This essentialy allows to write macros using #define (and correctly handle
line numbers when using #include). gpp also has some extensions to cpp that
can be useful with jal (like user-definable comment syntax, immediate macro
evaluation, ...).
I attach the unified diff patch agains the cvs version of jal.
I hope that this could be useful to someone else beside me.

Cheers,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

hi All,

I just encountered the following problem

I've a function "detect_US", which should return true when a valid
US-echo is detected

In the main program I call the function like this
<JAL>
   if detect_US then
     asynch_send_hw (US_distance)
   end if
</JAL>

This worked perfect, at least I thought ;-)

For test purposes, I removed "asynch_send_hw" call
and the result was that about my whole program was optimized away :-(

Strictly speaking, this optimization was a correct action,
because I forgot to set a return value in the function "detect_US".
(The US-distance was also transmitted in another place,
therfor I thought the program worked correctly).
And main problem is that the function detect_US was never called !!

So I think at least it's inconsequent to optimize away or not
the function detect_US,
depending on if the "if-statement" contains any functional code.

It would also be a good idea to give a warning when no return value is
set in a function.

Stef