On 12/03/2013 09:04 AM, Travis Griggs wrote:
> Having forayed into the world of small small micro controllers myself
> this last year and a half, I’m kind of torn on whether this is a good
> idea or not. But I think it’s cool they’re trying. And I’d definitely
> try it to see how it worked out.
I'
On 12/03/2013 07:18 AM, Colin J. Williams wrote:
> On 03/12/2013 7:58 AM, Mark Lawrence wrote:
>> I thought this might be of interest
>> Http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
>>
>>
> Is this intended to be better than
On Dec 3, 2013, at 6:18 AM, Colin J. Williams wrote:
> On 03/12/2013 7:58 AM, Mark Lawrence wrote:
>> I thought this might be of interest
>> Http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
>>
>>
> Is this intended to be bett
On 03/12/2013 7:58 AM, Mark Lawrence wrote:
I thought this might be of interest
Http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
Is this intended to be better than the Raspberry PI? RPi handles Python
2 or 3.
How would it differ?
Colin W.
--
https
I thought this might be of interest
Http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo
Peter Hansen wrote:
> (Not trying to argue, just understand, because it looks like you're
> conflating Forth programs with Forth implementations, or perhaps I'm
> even more ignorant than noted above and am missing a key point. :-)
It's decades since I coded Forth, but I suspect that Forth compil
Evil Bastard wrote:
> Peter Hansen wrote:
>>grabbing
>>an off the shelf Forth might be a more productive use of your time.
>
> Heh, methinks one might be misunderstanding the Forth culture.
Lacking entirely in any knowledge of it whatsoever would be a more
accurate description. "Ignorant of" is
Peter Hansen wrote:
> So while it would probably make an
> interesting project, and I'm pretty sure it's quite feasible, grabbing
> an off the shelf Forth might be a more productive use of your time.
Heh, methinks one might be misunderstanding the Forth culture.
Forth compilers are like poetry, i
Peter Hansen wrote:
> So while it would probably make an
> interesting project, and I'm pretty sure it's quite feasible, grabbing
> an off the shelf Forth might be a more productive use of your time.
Heh, methinks one might be misunderstanding the Forth culture.
Forth compilers are like poetry, i
Evil Bastard wrote:
> Paul Rubin wrote:
>> Pick a different language.
>
> Maybe I should clean up my forth compiler instead, and get it ready for
> the prime time.
In searching for an existing Lua virtual machine** for the PIC,
following on my previous posting, I came across several references t
language.
On thinking about it, you might be right.
Unless one implements a full dynamic OO engine, the prospect of
implementing python for microcontrollers resembles the task of moving a
palace's furnishings into a trailer park - you'll get a couple of things
into the trailer, but will h
David Cuthbert wrote:
>Paul Rubin wrote:
>
>
>>I don't think you want to do this. Runtime type tags and the overhead
>>of checking them on every operation will kill you all by themselves.
>>Processors like that haven't been used much as Lisp targets either,
>>for the same reasons. Pick a diffe
Hi Bastard,
one of the main reasons PyPy gets funded by the EU was the promise to
port Python to embedded systems ( but not necessarily very memory
restricted ones ). The project seems to be in a state where the team
tries to get rid of the CPython runtime alltogether and reaching some
autonomy. T
Paul Rubin wrote:
> I don't think you want to do this. Runtime type tags and the overhead
> of checking them on every operation will kill you all by themselves.
> Processors like that haven't been used much as Lisp targets either,
> for the same reasons. Pick a different language.
I was thinking
How about just helping this project:
http://pyastra.sourceforge.net/
I know he's trying to rewrite it to work across multiple uC's (AVR,msp430 etc)
HTH,
Guy
Evil Bastard wrote:
> Hi all,
>
> I'm currently tackling the problem of implementing a python to assembler
> compiler for PIC 18Fxxx mic
Evil Bastard <[EMAIL PROTECTED]> writes:
> Yes, this approach sucks. But can anyone offer any suggestions which
> suck less?
I don't think you want to do this. Runtime type tags and the overhead
of checking them on every operation will kill you all by themselves.
Processors like that haven't been
Evil Bastard wrote:
> Benji York wrote:
>>Perhaps porting Pyrex would be easier.
> Pyrex totally rocks. But for the PIC targetting, no can do:
...
> Any other suggestions?
Yes, port Lua instead. Lua is pretty much designed for this sort of
application, and is probably "Pythonic" enough to pro
Benji York wrote:
> Perhaps porting Pyrex would be easier. Pyrex takes a python-like syntax
> (plus type information, etc.) and emits C, which is then compiled.
Pyrex totally rocks. But for the PIC targetting, no can do:
- pyrex generates a **LOT** of code, which makes extensive use of the
py
Evil Bastard wrote:
> I'm currently tackling the problem of implementing a python to assembler
> compiler for PIC 18Fxxx microcontrollers
Perhaps porting Pyrex would be easier. Pyrex takes a python-like syntax
(plus type information, etc.) and emits C, which is then compiled.
--
Benji York
--
Hi all,
I'm currently tackling the problem of implementing a python to assembler
compiler for PIC 18Fxxx microcontrollers, and thought I'd open it up
publicly for suggestions before I embed too many mistakes in the
implementation.
The easy part is getting the ast, via compiler.ast. Also easy is
g
20 matches
Mail list logo
