Sven,
Tonight I tried to "make all" from your branch and wasn't able to build.
This is a the output I got:
http://pastebin.com/GQh5XA2w
I am guessing your build requires a working version of your fpc binary to
build itself.
Also, I wrote a few of pretty clean test cases in Delphi 2010 Today whe
On 29 Aug 2011, at 22:42, Sven Barth wrote:
> On 29.08.2011 22:22, Sven Barth wrote:
>> Without debug information it works. Next step: creating one of the
>> Android classes from within FPC compiled code. :)
>
> Ok... creating an Android class (in this case android.widget.TextView) from
> withi
On 29.08.2011 22:22, Sven Barth wrote:
Without debug information it works. Next step: creating one of the
Android classes from within FPC compiled code. :)
Ok... creating an Android class (in this case android.widget.TextView)
from within my FPC class works, but the full FPC variation still do
On 29.08.2011 00:56, Jonas Maebe wrote:
On 28 Aug 2011, at 23:01, Jonas Maebe wrote:
The org.freepascal.rtl.system class verifies fine here, and the FpcBitSet stuff
also works fine. Maybe the methods of java.util.BitSet (on which
org.freepascal.rtl.FpcBitSet is based) have different signatur
Wow, Sven, thanks for the reply, and most definitely thanks for working
on FPC. Anything I can do to help I'll do. Last week I sent patches to
fix issues with Lazarus CodeTools and the new generic syntax which
basically caused a lot of problems in the IDE.
I'll be on freenode irc in both #fpc and
Michael Schnell schrieb:
The JVM bytecode is a pure stackbased one while the Dalvik one uses
registers.
Yep.
That is why I am astonished that converting Java-Bytecode to Dalvik code
should be an easy task.
A stackbased internal or intermediate representation is the most general
one, from
On Mon, Aug 29, 2011 at 11:19 AM, Sven Barth wrote:
> Hi!
>
> As Paul and Jonas already told you, I'm currently working on improving the
> compilers generic implementation. As you have noticed it currently doesn't
> support generic methods and constraints at all. Also the generic
> implementation
Hi!
As Paul and Jonas already told you, I'm currently working on improving
the compilers generic implementation. As you have noticed it currently
doesn't support generic methods and constraints at all. Also the generic
implementation in mode Delphi isn't working correctly as you've noticed.
I
>
> Try rev 18900
>
> I think I fixed all issues
>
That was quick :)
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 29 Aug 2011, at 16:50, Anthony Walter wrote:
Btw, where would be a good place to follow your progress on
JVm support?
Here :) And also the svn commit log of http://svn.freepascal.org/svn/fpc/branches/jvmbackend
, as well as http://wiki.freepascal.org/FPC_JVM and its subpages
(probably e
Thanks Jonas. Btw, where would be a good place to follow your progress on
JVm support?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 29 Aug 2011, at 16:23, Anthony Walter wrote:
Paul, thanks for the reply. Did you mean to say that the generics are
actually being improved ... that is that someday you might be able
to say:
procedure TMyNonGenericClass.MyGenericMethod(List: TList);
Or that the random seeming bugs with t
Oh, and FPC generics really need the ability to add constraints ...
e.g. type TObjectList = class TList ... end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Mon, Aug 29, 2011 at 10:15 AM, Paul Ishenin wrote:
> Yes. These are known problems and you would found even more a year ago.
> Sven Barth now trying to fix exising problems and implement missing things.
>
> If you wish to try fix them yourself you need to study how parser part of
> the compile
29.08.2011 21:52, Anthony Walter wrote:
Jump to "So here are some of the problems I've found with fpc
generics" if you don't want to read the backstory.
...
And if someone ever does intent to fix generics in FPC, there are a
whole slew of errors that they already bring into the compiler. I'll
Try rev 18900
I think I fixed all issues
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Jump to "So here are some of the problems I've found with fpc generics" if
you don't want to read the backstory.
I haven't been active in the FPC for a while, but last week I was asking
some questions about the upcoming Delphi FireMonkey project which is
supposed to allow broader development with
>
> ops... fixed in rev 18893
>
Got the file.
Several issues though:
- a lot of the integers should be ptrint for 64 bit processors. That work has
been done already in SynRegExpr.pas in the LCL.
- the file lost its UTF8 characters somewhere. In RegExpr you'll find
RusRangeLo = 'àáâãäå¸æçèéêë
ops... fixed in rev 18893
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
> > Something went wrong with the commit. The rename worked but the new
> > regex.pp
>
> There is no new regex.pp, I did not modify this file, it is
> still Joost's version.
>
> Sorokin's RegExpr is all in one file: RegExpr.pas therefore I
> did not see a need to touch regex.pp
>
And where i
On Mon, Aug 29, 2011 at 2:31 PM, Ludo Brands wrote:
> Something went wrong with the commit. The rename worked but the new regex.pp
There is no new regex.pp, I did not modify this file, it is still
Joost's version.
Sorokin's RegExpr is all in one file: RegExpr.pas therefore I did not
see a need t
> I added Sorokins RegExpr to packages in rev 18891 introducing
> the following incompatibility:
>
Something went wrong with the commit. The rename worked but the new regex.pp
isn't committed:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/regexpr/src/
Upackages\regexpr\fpmak
On 29 Aug 2011, at 14:15, Felipe Monteiro de Carvalho wrote:
Is this expected?
Only a complete "make all" in the top level FPC directory is
guaranteed to work when starting with the latest release. The packages
are compiled with the newly compiled compiler and hence may not be
compilabl
Hello,
[felipe@localhost paszlib]$ make
/bin/mkdir -p units/i386-linux
/usr/bin/ppc386 -Fu../../rtl/units/i386-linux -Fu../../packages/hash
-FE. -FUunits/i386-linux -di386 src/paszlib.pas
Free Pascal Compiler version 2.4.4 [2011/04/22] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Note: Swi
On 08/29/2011 01:09 PM, Jonas Maebe wrote:
JIT compilers for Java byte code have existed for over a decade now.
They also map the Java stack machine to register-based architectures.
Of course they do.
Seemingly the Dalvik "to-dex-converter" is supposed to do some static
pre-processor work on
Place for some docs:
http://wiki.lazarus.freepascal.org/Regexpr
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I added Sorokins RegExpr to packages in rev 18891 introducing the
following incompatibility:
http://wiki.lazarus.freepascal.org/User_Changes_Trunk#regexpr.pp_was_renamed_to_oldregexpr.pp
The main file from Joost Reg Expresions was RegEx.pp so probably many
users won't be affected.
--
Felipe Mon
On 29 Aug 2011, at 11:42, Michael Schnell wrote:
On 08/29/2011 11:08 AM, Sven Barth wrote:
But there is a significant difference between the JVM bytecode and
the Dalvik one and perhaps Michael thought of that when writing his
question:
The JVM bytecode is a pure stackbased one while the D
On 08/27/2011 04:33 PM, Marco van de Voort wrote:
Not all permission bits have constants predeclared. Michael and I checked
and Linux/FreeBSD/Darwin all have the upper bits declared like this:
#define S_ISUID 0004000 /* [XSI] set user id on execution */
#define S_ISGID 00
On 08/29/2011 11:43 AM, Felipe Monteiro de Carvalho wrote:
Sven is correct. I didn't know this until now, but all Android
applications are first compiled using javac and then dex converts the
bytecode. Usually you don't have to care about this, because the Java
part is provided in source code and
On Mon, Aug 29, 2011 at 11:42 AM, Michael Schnell wrote:
> That is why I am astonished that converting Java-Bytecode to Dalvik code
> should be an easy task.
Sven is correct. I didn't know this until now, but all Android
applications are first compiled using javac and then dex converts the
byteco
On 08/29/2011 11:08 AM, Sven Barth wrote:
But there is a significant difference between the JVM bytecode and the
Dalvik one and perhaps Michael thought of that when writing his question:
The JVM bytecode is a pure stackbased one while the Dalvik one uses
registers.
Yep.
That is why I am as
Of course I did understand this. I suppose the virtual "Java Processor"
in fact uses 32 or 64 bit data. But the instruction coding might (or
might not) be quite different when doing a byte-encoded instruction set
(like a X86 processor) or using another instruction width (like ARM).
-Michael
__
Am 29.08.2011 10:58, schrieb Jonas Maebe:
On 29 Aug 2011, at 09:58, Michael Schnell wrote:
How did you manage to move from the 8 bit SUN Java bytecode to the 16
bit Android /Dalvik code ?
You are thinking of 8 and 16 bit in the wrong way. Those are simply
details of the respective byte code
On 29 Aug 2011, at 09:58, Michael Schnell wrote:
How did you manage to move from the 8 bit SUN Java bytecode to the
16 bit Android /Dalvik code ?
You are thinking of 8 and 16 bit in the wrong way. Those are simply
details of the respective byte code instruction formats. For example,
it's
Am 29.08.2011 09:58, schrieb Michael Schnell:
On 08/27/2011 05:43 PM, Sven Barth wrote:
So it is definitely possible to run FPC JVM code on Dalvik, it's just
not working perfectly currently...
Sorry if this is a stupid question from still-JAVA-ignorant:
How did you manage to move from the 8
On 08/27/2011 05:43 PM, Sven Barth wrote:
So it is definitely possible to run FPC JVM code on Dalvik, it's just
not working perfectly currently...
Sorry if this is a stupid question from still-JAVA-ignorant:
How did you manage to move from the 8 bit SUN Java bytecode to the 16
bit Android
37 matches
Mail list logo
