On 09/26/2014 10:00 PM, Boian Mitov wrote:
We already implement equivalent of signals as I mentioned in
Mitov.Runtime, however they are anonymous methods based, and we call
them TMultiProc but they are the same thing. I even showed a code
snippet in another post.
Interesting stuff !!
Is
On 09/26/2014 06:06 PM, Mark Morgan Lloyd wrote:
Different implementations could potentially use either local threads
or OpenMPI.
Yep.
With Local Thread you supposedly mean user land threads. Same would
need to be implemented together with an appropriate set of synchronizing
functions. Seems
On 09/26/2014 10:05 PM, Boian Mitov wrote:
If ARC is missing you need to call free. No Critical section is
involved with that.
Incorrect the pointer on which you call free needs to be guarded.
Only if it is used in a way that asks for this. Whether or not it is
done is up to the user.
IMHO it usually is better to first decide if you want to drink tea or
bear before you run to the fridge or to the cupboard.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
In fact (to avoid an inconsistency with implementing
TApplication.QueueAsyncCall) I suggested that I could do a (rather
simple) patch for the future release of the RTL that provides a more
appropriate Queue-feeding function than TThread.Queue. This attempt had
been discouraged.
Seemingly
On 09/29/2014 10:55 AM, Mark Morgan Lloyd wrote:
to ensure that the inner loop is parallelised to the greatest possible
extent, but that the outer loop is protected from reentry.
Of course you are right.
I did this example to show that the compiler magic should be able to
handle nested
Yesterday, I had a discussion with a colleague about programming languages.
He said that he did not like Object-Pascal / fpc because it lacks the
concept of signals he finds in other languages / libraries. (He is not
an expert but discusses on base of rumors he collected.)
With signals he
On 09/25/2014 05:11 PM, Sven Barth wrote:
Of course the user can see it.
But he does not _need_ to. :-)
Namely to introduce refcounting to classes where he/she can't
influence the parent class (simple example: a TStrings descendant)
Sounds like a great concept.
-Michael
On 09/25/2014 07:27 PM, Boian Mitov wrote:
What I am saying is that the parallel loop handles only one specific
case of parallelization, and with limited options.
A library implementation on the other hand offers full flexibility.
Of course I did understand that.
What I was saying that
On 09/25/2014 07:30 PM, Boian Mitov wrote:
Strongly disagree...
You can't deny it. Please read some technical docs about the cost of
interlocked operation in multicore systems.
As compare to the cost of other locking methods such as critical
sections that have to be implemented instead if the
On 09/25/2014 05:14 PM, Sven Barth wrote:
ARC objects will only be destroyed when the last reference to them has
gone out of scope. If there is still a reference, then there's still
the object.
I understood, the example showed that the object might survive even if
there is no reference any
On 09/26/2014 09:39 AM, Michael Van Canneyt wrote:
You can use the Observer pattern; it is in the classes unit.
I'll take a look.
And to be honest, this is not a language concept, but a library concept.
AFAIK he mentioned QT as a library providing this.
It can be easily implemented.
If
On 09/26/2014 10:19 AM, Martin Schreiber wrote:
Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so
easy to implement as it seems. ;-)
Nice :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/26/2014 10:38 AM, Michael Van Canneyt wrote:
To allow for doing this with thread, an event queue for worker
threads needs to be provided.
Huh? WHY ?
When handling asynchronous Events with a thread, you need an event queue
and a mechanism to have the thread sleep until the queue gets
On 09/26/2014 10:58 AM, Michael Van Canneyt wrote:
Absolutely. A signaling mechanism, synchronous, is not hard.
I suppose an _synchronous_ mechanism can be done on base of or similar
to Dispatch.
But the signaling mechanism we talked about is obviously asynchronous.
-Michael
On 09/26/2014 11:12 AM, Michael Van Canneyt wrote:
But the signaling mechanism we talked about is obviously asynchronous.
This may come as a shock to you, but no, it is not obvious.
???
I described: sending Signals from one thread to one or more others,
sender and receipient can be as
On 09/26/2014 11:37 AM, Sven Barth wrote:
In Qt it does. Each QObject has a thread it is owned by and thus the
signal handling mechanism knows to which thread to queue to deliver a
signal to a certain object.
Making the appropriate (signalable) Objects instances of TThread
siblings would
On 09/26/2014 11:40 AM, Michael Van Canneyt wrote:
That is an implementation detail of Qt. Not so in FPC.
Correct.
Hence - if you say the signaling stuff is not / should not be a language
feature but just a matter of a library (I don't disagree here) fpc is
unrelated to this. I feel that fpc
On 09/26/2014 11:36 AM, Mark Morgan Lloyd wrote:
so that we're not groping in the dark based on your account of his
recollection of the rumours he's picked up from sources that might not
be reliable.
I was just trying to help fpc to be a winner (here and elsewhere). ;-)
In fact it seems that
On 09/26/2014 01:41 PM, Reinier Olislagers wrote:
Which reminds me - how is that library (non-GUI event loop IIRC) coming
along? Is there any code repository where interested people can look?
As I already pointed out multiple times it works just fine for me, but
can't be included in the LCL
On 09/26/2014 01:57 PM, Reinier Olislagers wrote:
So why not include your own version of TThread with IFDEFS to
check for FPC version so it can be retired when an FPC 2.7.1+ is
used/stable?
I don't suppose it makes sense to do a version of TThread that does not
reside in the rtl / and classes
On 09/26/2014 02:09 PM, Reinier Olislagers wrote:
Well, that says a lot, I suppose.
As it did work for me, it says that nobody is interested in an
ActiveNoGUI Widget Type for Lazarus right now.
I can use it with the svn version of fpc if I want to.
So I decided to hold off until the released
Thinking harder I remember that I did not send it to the Forum but in a
private mail to the one person who seemed interested.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote:
.
A parallel loop syntax is very attractive, but the practical
difficulty is that it would probably have to sit on top of threads and
getting code distributed promptly over multiple worker threads, i.e.
starting up within 10s of nSec rather
On 09/23/2014 09:51 PM, Peter Popov wrote:
, I will restate the obvious:
using reference counting will decrease parallel performance
You are perfectly right.
So you should try to avoid heavy ref counting (i.e focusing / defocusing
ref counted stuff, including Strings) in multithreaded code.
On 09/23/2014 11:09 PM, Boian Mitov wrote:
Correct you will lose ~3 assembly instructions (Interlocked
increment/decrement-exchange, and conditional)
With modern x86 archs, interlocked instructions are very expensive in
themselves and can take thousands of clock cycles due to cache
On 09/22/2014 02:34 PM, Sven Barth wrote:
I already suggested the addition of a TARCObject as a general
reference counted base class in my RFC ;)
Sounds nice, but is it (easily) possible to implement that the compiler
magic for doing the ref-counting is issued exactly whenever the
On 09/22/2014 08:51 PM, Boian Mitov wrote:
I am not big fan of the compiler handling parallel loops, as it will
limit any flexibility in implementation.
A library based functionality with shared executors is a better
design, and it allows not only for parallel loops but also for easy
parallel
On 09/22/2014 10:07 PM, Boian Mitov wrote:
Adding simple parallel loop lacks any of this power, and only serves
very specific cases.
As the parallel loop syntax would be nothing but syntax candy to easily
make use of a thread pool library, nobody would prevent the user from
directly use
On 09/22/2014 10:17 PM, hinstance wrote:
If it is a game, even 200 ms freeze would be annoying.
We do lots of embedded applications using Pascal. unavoidable Stop of
World would be End of World.
-Michael
___
fpc-devel maillist -
On 09/22/2014 11:25 PM, Sven Barth wrote:
Considering that those are two different features that don't have
anything to do with each other their development doesn't need to be
serialized, but can happen in parallel ;)
Will the destructor of a reference counted object not be a kind of
On 09/22/2014 08:34 PM, Boian Mitov wrote:
Strongly disagree...
You can't deny it. Please read some technical docs about the cost of
interlocked operation in multicore systems.
Doing parallel processing without ARC is practically suicidal IMHO.
That might well be, but it does not deny the
On 09/23/2014 01:58 AM, Hans-Peter Diettrich wrote:
Why inherit when you can't override virtual methods?
Easily adding field.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/22/2014 08:37 PM, Boian Mitov wrote:
Honestly if you don’t know what you are doing when using ARC, I doubt
a bit, you really know what you are doing otherwise either ;-) .
Ref counted strings are no problem with any (normal) use of same.
In this thread you find an example describing how
On 09/25/2014 11:52 AM, Sven Barth wrote:
TARCObject would just be provided for convenience reasons. The real
magic is a keyword that can be used for any class to enable ARC for
that class and all it's descendant.
I see. Hence, technically, there would be a kind of attribute syntax,
but
On 09/25/2014 11:55 AM, Sven Barth wrote:
Why should it? When the reference count is decreased to zero (and thus
the final reference on the instance is gone) the destructor method is
executed (which is just a obj.Destroy;), simple as that (in reality
it's a bit more complex, but that's an
AFAIR there already were several debates on ARC Objects that seem do be
a modern language feature but in Pascal language they are considered
to provide lots of pitfalls.
Why not use interface to add ref-counting to an object ? This seems to
work nicely even though the name interface in not
On 09/20/2014 01:42 PM, Sven Barth wrote:
a farmer doesn't eat what he doesn't know
Really healthy laughter from Germany,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/21/2014 07:17 PM, Boian Mitov wrote:
In general I would prefer to see this implemented with attributes
rather than with new keywords.
Yet another attribute to class.
This might (re-)trigger thought about a complete rework of of
record-enhancing types and allow for the record and object
On 09/20/2014 08:33 PM, Giuliano Colla wrote:
Can you explain how reference counting can be safely implemented in a
parallel multithreaded environment, without heavily affecting performance?
*Very* good point !
IMHO a by far more advantageous feature to be added than ref-counted
objects would
On 09/21/2014 06:36 PM, Boian Mitov wrote:
I consider it a design bug that local functions can't be passed as
anonymous methods in Delphi. There is no reason for that not to be
done, except that they did not bother.
???
Local functions can use local variables of the outer function. Same are
On 09/20/2014 08:04 PM, Boian Mitov wrote:
This is actually a very good idea IMHO!
I would vote for it. Record inheritance is something I miss badly in
Delphi.
As said in a previous mail: why have Record ad all, if you want things
like inheritance (and active properties, ...) Maybe multiple
On 09/22/2014 11:13 AM, Sven Barth wrote:
Interfaces, strings and arrays already work well in multi threaded
contexts and ARC will use the same mechanisms here, so there is no
need to discuss parallel and ARC together.
Yep. it will work.
But one point speaking against ARC is performance
On 09/22/2014 11:15 AM, Sven Barth wrote:
Because you'll need to declare an interface for each class you want to
have reference counted so that you can access its methods, properties,
etc.
Con: more typing
Pro: you know what you are doing.
-Michael
On 09/22/2014 11:54 AM, Peter Popov wrote:
Because you'll need to declare an interface for each class you
want to
have reference counted so that you can access its methods,
properties,
etc.
Con: more typing
Pro: you know what you are doing.
I cannot agree more.
Another con:
On 09/22/2014 07:52 AM, Sven Barth wrote:
I openly *hate* the attribute syntax. It's just not Pascal and simply
copied from their .Net compiler, because hey, other .Net compilers do
that just like that... -.-
Maybe instead of attribute appropriate base classes could be provided.
E.g. a
On 09/22/2014 02:34 PM, Sven Barth wrote:
I already suggested the addition of a TARCObject as a general
reference counted base class in my RFC ;)
So I am proud to have independently recreated your idea :-)
-Michael
___
fpc-devel maillist -
On 09/22/2014 02:51 PM, Sven Barth wrote:
Then you should also not use interfaces, strings and arrays, because
they use the same mechanisms.
Yep. The advanced developer should know what he is doing.
What us confusing there?
Of course I do know the pitfalls.
If fpc would provide a
On 09/22/2014 02:19 PM, Hans-Peter Diettrich wrote:
AFAIK *variant* records (currently) can not be replaced by something else.
I suppose you are right, but maybe appropriate syntax can be introduced
to class definition that might be helpful in certain instances.
-Michael
On 09/22/2014 02:05 PM, Hans-Peter Diettrich wrote:
TMyARCclass = interface(TObject)
IMHO, Sven's idea of introducing a TARCObject base class (triggering
the compiler magic for ref counting) sounds a lot nicer.
-Michael
___
fpc-devel maillist -
On 09/08/2014 10:54 PM, Michael Ring wrote:
This smells like a problem I had on pic32. In my case the pic32 chips
do not have a floating point unit and the processor creates an illegal
instruction (or something similar) exception.
I solved this for me by patching out the call to the hardware
On 09/02/2014 04:08 PM, Michael Ring wrote:
I guess it depends on what you understand by the word support ;-)
Regarding support, a first issue would be some kind of TODO-List /
documentation e.g. in the Wiki.
Then, I suppose (but I don't know what exactly would be involved) that a
dedicated
As the MIPS32 CPU now is supported, and I am involved in several PIC32
projects, I am very interested in possibilities to use FPC on this cheap
and versatile chip.
While up till now I only knew the MPLABX IDE (including C compiler and C
libraries) by Microchip, that needed to be attached to
On 08/23/2014 06:17 PM, Dennis Poon wrote:
Oh I see now. The old object style used in turbo pascal!
Your original question was about TObject.
AFAIK, old style TP Object is depreciated and usually can be replaced
by records containing methods.
-Michael
On 08/25/2014 02:49 PM, Marco van de Voort wrote:
As I said, that is a limited use :_)
IMHO, a static or similar keyword for a class type definition would
nicely allow for doing away with Object and Record altogether..
-Michael
___
fpc-devel
On 08/25/2014 04:19 PM, Marco van de Voort wrote:
IMHO it would bring the sometimes maps 1:1 to record, sometimes not misery
of object back again, while I would rather have it gone.
Some incompatibility easily could occur, if you would remove the
dedicated support for Object and Record and
I found that my intent to do an active extension (or variant) of the
Lazarus NoGUI Widget Type (aka Interface) is not possible (to be
implemented in an IMHO sensible way) using the released version of the
FPC RTL, but is rather easy when using the TThread extensions provided
by the svn
On 08/20/2014 11:12 AM, Michael Van Canneyt wrote:
You can perfectly work around this by implementing
Application.QueueAsnycCall so that it creates a thread which does the
call to TThread.Queue.
Do you mean that for an implementation of Application.QueueAsyncCall I
should
- Check if we
On 08/20/2014 12:14 PM, Michael Van Canneyt wrote:
OTOH, as supposedly nobody ever on purpose calls
Application.QueueAsyncCall from the main thread it does not do much
harm (other than eating up some bytes of memory).
Exactly.
So I will proceed as you said.
Thanks,
-Michael
On 08/13/2014 03:30 PM, Michael Schnell wrote:
with the trunk version without using TThread.Queue.
The purpose being to make it run with the _released_ version (that does
not feature TThread.Queue), while I of course do my tests using the svn
trunk version.
-Michael
On 08/13/2014 03:30 PM, Michael Schnell wrote:
RTLEventResetEven
RTLEventSetEvent (sorry for sloppy cut and Paste)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 06/26/2014 02:53 PM, Michael Van Canneyt wrote:
You can perfectly just develop with trunk and be ready to release when
the trunk version is released as a stable version.
I finally was able to try to implement a version of my interface unit
that is supposed to work with the trunk version
On 08/03/2014 01:16 PM, Jonas Maebe wrote:
A position-independent executable is simply an executable that only
contains position-independent code and that is linked with the -pie
linker option. So compiling all code with -Cg (the standard FPC RTL
and packages are compiled like that by
On 07/20/2014 10:27 PM, Dmitry Boyarintsev wrote:
There's no block reserved word in FPC yet (unlike mentioned earlier
Oxygen).
AFAIU, many keywords are not reserved, but recognized only due to their
context. Hence somebody could have used block as a normal symbol. But
in block is compatible
On 06/27/2014 08:01 PM, Hans-Peter Diettrich wrote:
I don't see an advantage with using relative times, or unsorted lists.
On insertion a binary search over the list can be made, when the entries
are sorted by absolute time. Removal of entries occurs always from the
list head.
Relative Timers
On 06/28/2014 10:29 AM, Martin Schreiber wrote:
The MSEgui timers work with that approach too. I am sure Michael Schnell knows
lib/common/kernel/msetimer.pas.
The current source code is just a draft.
After a proof of concept (Single-Queue'ed, TTimer enabled NoGUI
Lazarus Widget Type) I
On 06/27/2014 11:31 AM, Henry Vermaak wrote:
The latest release (2.6.4) has clock_gettime() in unit linux.
On Debian I seemingly only have 2.6.0-9 :-(
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 06/26/2014 07:49 PM, Mattias Gaertner wrote:
Why can't you use trunk and $IFs like everyone else?
I do _need_ TThread.Queue (and I do _need_ TThread.GetTickCount64 (or
another decent timing source).
The released rtl version does not have TThread.Queue and for timing only
fpgettimeofday()
On 06/27/2014 10:19 AM, Mattias Gaertner wrote:
In other words: Nothing stops you, except yourself.
Yep.
(see the discussion in lazarus-devel.)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 06/26/2014 03:20 PM, Michael Schnell wrote:
P.S.: perhaps the project is not even doable (in a perfectly
compatible way) with the (Delphi compatible) implementation of
TThread.Queue. (I just would need to be able to feed an Event in the
Queue, but those means are private in TThread.) So
On 06/27/2014 12:54 PM, Giuliano Colla wrote:
1) a list of timer events, ordered by expiration time.
Thanks for the pointers.
I in fact do something similar.
My TTimer class has a class variable that is a dynamic array of TTimers.
When the program is going to wait for anything (a timer or a
HI fpc team,
for doing an extension to the Lazarus LCL, I need the
TThread extensions such as
- CurrentThread,
- Queue, and
- GetTickCount64
It already works fine with the svn version of fpc.
I installed the official X86-64 fpc release (Debian Package, provided
by the Debian store). This
On 06/26/2014 02:27 PM, Sven Barth wrote:
Am 26.06.2014 14:22 schrieb Michael Schnell mschn...@lumino.de
mailto:mschn...@lumino.de:
- what is the current official version ?
2.6.4
- does it have the TThread extensions ?
No
So I supposedly need to hold off this projects :-( .
-Michael
On 06/26/2014 02:53 PM, Michael Van Canneyt wrote:
Trunk is quite stable, the functionality you need is present since ages.
Did I commit inappropriate phrasing ?
I meant, I need to hold off the enhancement I have in mind until an rtl
version that provides TThread.Queue is officially
On 06/26/2014 03:31 PM, Michael Van Canneyt wrote:
You clearly didn't understand my remark. Please re-read it.
OK.
So your point is that I can do the development and hold-off just the
release.
If so:
- The development of the functionality (using the svn release of fpc)
id done and
On 06/26/2014 03:34 PM, Mattias Gaertner wrote:
2. If you insist using the new RTL features, then add the LCL features
using $IFs.
I do not _need_ anything. I just want to enhance the functionality in
the best possible way, if I can.
With the ActiveNoGUI Application there is no sensible way
On 06/26/2014 04:06 PM, Michael Van Canneyt wrote:
The lazarus team makes pretty sure that Lazarus compiles with released
and trunk versions.
Yep. Exactly this is why my would-be LCL enhancement needs to wait until
the next fpc release.
Really, I think you are looking for problems where
On 06/26/2014 03:57 PM, Mattias Gaertner wrote:
You can do it like the nogui widgetset. Application.QueuAsyncCall
works there.
You already stated that it only works if the user calls
Application.ProcessMessages. This is not what I am up to.
(I'll take a look at the NoGUI implementation,
On 06/26/2014 04:34 PM, Michael Van Canneyt wrote:
Strange. I came to exactly the opposite conclusion.
Sorry. I am not able to understand your argument :-( .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 05/26/2014 08:25 PM, Sven Barth wrote:
Here... happy now? ;)
Very happy indeed :-) .
(Silly me did not remember the ClassName property. With same the test
is as easy as you showed.)
Now thinking about why I had been confused is that obviously self of
an instance _does_ determine the
On 05/27/2014 02:55 AM, Ralf Quint wrote:
Very common, and very cheap... ;-)
And hence very useful when you want do do mass products.
But for any projects below 10.000 pieces to do I would try to take
advantage of the benefits of modern 32 Bit archs E.g. very versatile PIC
32 chips (MIPS
On 05/23/2014 07:39 PM, Daniel Sapundjiev wrote:
Can someone help me with the 8 bit AVR.
Do you really plan to sell a device in such great quantities that it
makes sense do invest a lot of software engineering effort in an 8 Bit
arch instead of one of the (better) supported 32 Bit archs,
I found out that I need to add static to the get class procedure to
allow it's usage in a class property.
Sorry for the noise :-[
If fact I don't understand what the additional static is necessary. I
was of the op pinion that class procedures are static, anyway.
Can somebody clarify ?
On 05/26/2014 11:37 AM, Sven Barth wrote:
Where did he say that he wants to sell anything? Maybe he just wants
to try FPC on AVR 8-bit for fun?
OK :-) :-) :-)
(For me, this fun would be too expensive in terms of engineering effort.)
Have fun,
-Michael
On 05/26/2014 12:52 PM, Ewald wrote:
A `Class Procedure/Function XXX;` has a hidden parameter that points to the
classtype. A `Class Procedure/Function XXX; static;` doesn't have this hidden
parameter.
I see.
The hidden parameter would be accessed as Self ?
Thanks for the explanation !
On 02/27/2014 04:35 PM, Jonas Maebe wrote:
You have to declare an instance and then call its property. You don't
have to instantiate the instance if the property maps to a class method.
Technically there's some obstacle to allow such construct?
Class properties should be accessible from
On 04/23/2014 03:53 PM, Michael Ring wrote:
- we did not yet decide if we would want to link the fpc functions
statically or load and link them dynamically in some way.
For statical linking it would be essential to be able to use the xc32
linker with fpc generated object files.
For
I would simply create a record type and a pointer type to same and then
typecast an integer constant (=address) onto the pointer. Now you can
access the values by normal dereferencing.
-Michael
___
fpc-devel maillist -
On 04/23/2014 10:34 AM, Michael Ring wrote:
Thanks,
but does not solve the problem, it's not about reading the data, it's
about defining the data so that it is included in the elf file in the
correct section so that the microcontroller is programmed with the
values when the elf file is
On 04/23/2014 02:56 PM, Michael Ring wrote:
this code is for PIC32 ;-) , Florian has merged my initial work a few
weeks ago and Segger has created a new version of their J-Link probe
which supports pic32, so I am currently fine-tuning the code so that
Florian can merge the missing parts.
I
On 04/23/2014 02:56 PM, Michael Ring wrote:
this code is for PIC32 ;-)
I did some research on behalf of PIC32.
Here some of my latest results that might be of some interest.
- PIC32 MX uses (cost efficient) MIPS 4K Architecture, (40 MHz
chips with a single, 80 MHz chips with two register
Some questions that might put us in a working position:
Can you state the cause why xc32 is not usable ?
For our project (from your first message seemingly different form what
you are doing) we want to call fpc functions from running C-made code.
Hence
- initialization is no issue at all
The wiki page speaks of gdb. Does same use PICKit a similar tool to
connect to the chip ?
Of course it would be great to be able to use the debugger from withing
MPLABX. I suppose MPLABX just calls a gdb executable in a standard way,
so this might be possible.
-Michael
On 04/23/2014 03:53 PM, Michael Ring wrote:
Nope, my main focus is to get it running on bare metal, so dynamic
linking is of no relevance, I hope that I can statically link
Microchip libs to pascal code.
OK.
Once we get at this, we will be able to find (and publish) ways to link
fpc
On 04/05/2014 11:48 AM, Michael Van Canneyt wrote:
I've finally committed a first version of the pascal-to-javascript
conversion engine.
GREAT !
Thanks !
One additional side-chain thought:
I understand that the goal is to allow to compile Pascal programs to be
able to run inside a Browser.
Another slightly related question: did anybody try to use the fpc to
Java-Byte-Code compiler to create server-site Java CGI applications
(to get around the arch-dependance of native compiled fpc programs) ?
-Michael
___
fpc-devel maillist -
On 04/07/2014 10:16 AM, Michael Van Canneyt wrote:
I don't want Java. Just plain HTML and Javascript, standards-compliant.
I see. This does make sense.
But I see no reason why you would not be able to use the jvm to do
what you want.
I have no idea how to integrate Java Byte Code in a
On 03/13/2014 03:24 PM, Vsevolod Alekseyev wrote:
Consistently crashes when executed under a debugger, but ran as
expected 10 times in a row when standalone.
Under debugger you will constantly have interrupts. So this is as expected.
-Michael
___
On 03/11/2014 01:08 PM, Vsevolod Alekseyev wrote:
How interesting. Where's you hear this?
It's an obvious conclusion from your statement that any non-Thumb code
crashes.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 03/11/2014 03:12 PM, Vsevolod Alekseyev wrote:
For the record, all modern mobile SDKs that I know of use Thumb as the
default instruction set for native code compilation. And with Thumb-2
on ARMv7 cores, the performance is on par between ARM and Thumb. The
original Thumb, years ago, was
101 - 200 of 1709 matches
Mail list logo
