Re: [fpc-other] who of us could try to improve javcl project

[Sven Barth via fpc-other]

Best ask your questions related to Android (be it with JVM or not) on 
https://forum.lazarus.freepascal.org/index.php/board,43.0.html for 
native Android and 
https://forum.lazarus.freepascal.org/index.php/board,56.0.html for JVM. 
There are more users registered that can help than here on fpc-other. 
Not to mention the developer of LAMW is there as well who might be 
willing to help improve LAMW for your needs (also it should be possible 
to use LAMW without LFM files and instead generate the components in code).


Regards,
Sven

Am 04.08.2020 um 18:41 schrieb Mgr. Janusz Chmiel via fpc-other:

The main reason why I Am opening this topic is The fact, that there is
currently no Opensource or free project, which would support all possible
GUI object types for Android when I Am not writing about Lamw.
Lamw will be never usable for visually impaired programmers, because it is
necessary to respect its visual based design. LFM language require using
object position values.
Pandroid support some basic object types, but adding next 40 or more GUI
Android element types such as tree view, combobox, checkbox, checklist is
very complex for A standalone Pandroid author.
As A result it is not possible to use The most modern Android features by
visually impaired Pascal programmers.
Lamw do not support all Android APi functions too, it do not contain
wakelock support, ignore battery optimisations, etc.
The question is, if somebody would have A good will to make this free
project. Because if it will be only attractive for visually impaired users,
it will not be attractive for somebody advanced to vaste his expensive
programming time.
How to solve this rebus?
Sure, I Am ready to test. BUt it is too little for such project.

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other


___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] ARM is the future of desktop

[Sven Barth via fpc-other]

Am 02.07.2020 um 18:14 schrieb Santiago A.:

Hello:

Here is an interesting article by a ex-windows boss. He thinks that in 
a few years even desktops will be ARM and Intel will be residual. And 
obviously it will be a mayor problem to Microsoft, whose software is 
very tied to Intel platform.


https://www.zdnet.com/article/ex-windows-boss-apples-arm-based-mac-will-be-the-ultimate-developer-pc/


Windows 10 nowadays supports both ARM and ARM64, so I see no problem there.

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] I need ppcjvm for ARM64 architecture

[Sven Barth via fpc-other]

Am 27.04.2020 um 13:38 schrieb Mgr. Janusz Chmiel via fpc-other:

Dear specialists,
My long term dream is to develop simple Android IDE which will be able to
compile Pascal app based on PPCJVM to The fully functional .apk package. The
first what I would like to plea you is to give Me direct link to download
PPCJVM for ARM64. So PPCJVM, which can compile Pascal sources to .class
files.
Unfortunately, I do not know, who have developed Android build tools for
Android, not for Windows or for Linux and if those build tools can be
legally downloaded from somewhere.


We do not provide a compiler that can run on Android, but you can 
compile it yourself. Please note that I have not fully tested the 
following steps, but please feel free to ask back if you have problems.


You'll need the following:
- a FPC 3.2 RC1 installation (at least for now until we've released the 
final version); you can find it here: 
ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/ (just to avoid 
confusion: the aarch64-android mentioned there is *not* what you want 
right now)

- the sources for FPC 3.2 RC1 also available on that site
- the fpcjvmutilities.zip, if you don't have it already; it's available 
here: ftp://ftp.freepascal.org/pub/fpc/contrib/jvm/fpcjvmutilities.zip

- the NDK for the Android version you want to target

For this example I'll assume that you installed FPC 3.2 RC1 on a Linux 
in /opt/fpc. Thus the fpc binary will be available in /opt/fpc/bin/fpc 
and the units will be in /opt/fpc/lib/fpc/3.2.0rc1/units. The sources I 
assume to be in ~/sources/fpc/3.2.0 and the NDK (the directory 
containing "as" and "ld") as well as the fpcjvmutiltities I assume to be 
available in $PATH, otherwise you'll need to specify their paths using 
CROSSBINDIR for their corresponding steps.


First we create the Java compatible units and class files.

For this go to the directory with the FPC sources and execute the 
following (here you need to specify the fpcjvmutilties using CROSSBINDIR 
if you don't have them in PATH):


make crossall FPC=/opt/fpc/bin/fpc OS_TARGET=android CPU_TARGET=jvm

If this was successful do the following (the INSTALL_PREFIX will be the 
same directory you installed FPC in, in our example /opt/fpc):


make crossinstall FPC=/opt/fpc/bin/fpc OS_TARGET=android CPU_TARGET=jvm 
INSTALL_PREFIX=/opt/fpc


As next step you need to create a cross compiler for aarch64-android 
(here you need to specify the NDK using CROSSBINDIR if you don't have 
them in PATH):


make crossall FPC=/opt/fpc/bin/fpc OS_TARGET=android CPU_TARGET=aarch64

If this was successful you do a

make crossinstall FPC=/opt/fpc/bin/fpc OS_TARGET=android 
CPU_TARGET=aarch64 INSTALL_PREFIX=/opt/fpc


As the last step we need to cross compile the JVM compiler for 
aarch64-android. For this change into the compiler directory and execute:


make all FPC=/opt/fpc/bin/ppcrossa64 JVM=1

This will create a ppcjvm that you can run on an Android device. 
Additionally you will need all the files that were copied to the 
/opt/fpc/lib/3.2.0rc1/units/jvm-android directory. Now you only need to 
supply a suitable fpc.cfg file to the compiler and hope that the 
jasmin.jar assembler can run on Android.


I hope this helps you.

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] VSCode

[Sven Barth via fpc-other]

Am 28.04.2020 um 02:14 schrieb Graeme Geldenhuys:

On 26/04/2020 2:37 pm, Sven Barth via fpc-other wrote:

It's more lightweight than eclipse.

Well that's comparing Apples to Oranges isn't it? Yes originally Eclipse
was designed as an IDE for many languages, but it has grown to be so
much more - even a platform to base new applications on (similar to VCL,
LCL etc).

Granted I haven't played much with VSCode, but considering it is built
on the same foundations as Atom, Sublime Text... ie CSS/HTML engine,
they are quite resource intensive.

But then I guess I'm comparing them as pure text editors in the lines of
EditPad Pro, Vim, gEdit etc that uses a fraction of the memory (one
example of resource usage) to load the same set of files. eg: The last
time I tried Atom (2 months ago) it used 380MB to load a set of 10 large
Java files. jEdit used 180MB and EditPad Pro used 18MB. Vim was
something like 8MB - lol.


I meant that in the context of "I need a JDK installed". Which I usually 
don't have on my computers. On my current one I installed a JDK only a 
few weeks ago to test something with Ghidra, but before that I was happy 
without one. And I'll probably kick that one out again...


Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] VSCode

[Sven Barth via fpc-other]

Am 26.04.2020 um 14:28 schrieb Martin Frb:

On 26/04/2020 14:21, Sven Barth via fpc-other wrote:

Am 26.04.2020 um 14:03 schrieb Martin:

Just curiosity:

I recently see a lot of great efforts to make things more widely 
available (language server / debug adapter).


Often with reference to use in VSCode.

I wonder what the advantage or usecases are for using VSCode as an IDE?


- free and open source
- cross platform
- easy to setup
- support for a wide range of languages (syntax highlighting, the 
language servers) and environments (e.g. there's Arduino support 
which is leagues better than that of the Arduino IDE)
- if the language server is implemented well then good code 
completion as well


So matter of taste?
Same as some people prefer eclipse?


It's more lightweight than eclipse. And being written in JavaScript 
instead of Java it might feel easier accessible for people wanting to 
write extensions...


I was wondering how it compares (if used with FPC) to Lazarus. (Not 
saying that Lazarus has a monopoly, just interested in knowing the diffs)

I.e., maybe it offers some features that Lazarus does not have?


By itself it's very weak for Pascal code. However there is the 
OmniPascal extension that provides support for compiling Delphi and 
Lazarus projects and also provides a language server (it's more geared 
towards Delphi language than FPC's syntax however). It does however not 
provide a visual form designer.


TMS also provides their TMS Web Core for VSCode including a form 
designer (they probably created a form designer using their Web VCL).


Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] VSCode

[Sven Barth via fpc-other]

Am 26.04.2020 um 14:03 schrieb Martin:

Just curiosity:

I recently see a lot of great efforts to make things more widely 
available (language server / debug adapter).


Often with reference to use in VSCode.

I wonder what the advantage or usecases are for using VSCode as an IDE?


- free and open source
- cross platform
- easy to setup
- support for a wide range of languages (syntax highlighting, the 
language servers) and environments (e.g. there's Arduino support which 
is leagues better than that of the Arduino IDE)
- if the language server is implemented well then good code completion 
as well


Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Delphi 10.4

[Sven Barth via fpc-other]

Am 11.04.2020 um 14:56 schrieb Marco van de Voort:


Op 2020-04-11 om 14:45 schreef Sven Barth via fpc-other:


2: management operators for records, maybe also simple record 
inheritance to reuse e.g. a refcount record pattern


Yay me, we got something incompatible again...



3: (also?) having some of the iOS refcounted classes system for the 
windows targets?


I personally think the other way round. But we'll see...


Yes, some people on the Delphi forum also pointed me to

https://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html

so it seems that ARC is dodo.


So I hadn't dreamed that I had read that somewhere :P Thanks for the link.

I wonder if managed records with default properties (like Maciej had 
planned) will be a better way to solve this...


Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Delphi 10.4

[Sven Barth via fpc-other]

Am 27.03.2020 um 11:39 schrieb Marco van de Voort:

Some early info about new Delphi 10.4 features

https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription 




1 Language Server Protocol for Delphi

2 Language Enhancements: Managed Records

3 Unified memory management across all platforms


my guesses:

1: no idea.


If I had to guess probably support for the language server functionality 
used in Visual Studio Code.




2: management operators for records, maybe also simple record 
inheritance to reuse e.g. a refcount record pattern


Yay me, we got something incompatible again...



3: (also?) having some of the iOS refcounted classes system for the 
windows targets?


I personally think the other way round. But we'll see...

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] [fpc-devel] Object upgrades

[Sven Barth via fpc-other]

Am 17.06.2019 um 20:01 schrieb wkitt...@windstream.net:


Also I never had to configure my Thunderbird in any special way to 
have the messages fully on my system...



because most default to using IMAP these days... when you say "fully 
on your system", do you mean that you can disable your modem and still 
access and read all your mails?? that's what we look at...
Yes, exactly that. I have it set up this way on all my systems so that I 
- especially on my mobile computers - can read (existing) mails while 
I'm on the train or whatever.


Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] [fpc-devel] Object upgrades

[Sven Barth via fpc-other]

 schrieb am Mo., 17. Juni 2019, 14:44:

> On 6/17/19 1:52 AM, Sven Barth via fpc-other wrote:
> > I use IMAP, so that could also be part of the explanation...
>
>
> i had a feeling that you were using IMAP... most folks these days do use
> it... i
> never liked it because 1) it puts more load on the server and 2) unless
> you take
> special care to make sure the messages are pulled to your device, they may
> be
> lost if the server has a problem and backups can't be restored somehow...
>

I seriously doubt that Google's servers can't deal with that additional
load. 
Also I never had to configure my Thunderbird in any special way to have the
messages fully on my system...

Main advantage of IMAP: it doesn't matter with which computer I check my
mails and I have multiple ones that have that account set up. 

Regards,
Sven

>
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] [fpc-devel] Object upgrades

[Sven Barth via fpc-other]

Tomas Hajny  schrieb am Mo., 17. Juni 2019, 02:47:

> On 2019-06-17 02:05, wkitt...@windstream.net wrote:
> > On 6/16/19 4:41 PM, Sven Barth via fpc-devel wrote:
> >> Am 16.06.2019 um 17:43 schrieb wkitt...@windstream.net:
>
>
> Switching to fpc-other, since this is certainly not on-topic on
> fpc-devel...
>
> >>> if gmail can determine that a message coming in from a list is one
> >>> you sent, it does not pass it on back to you... there's no way to
> >>> turn this off that i've found... they want you to use their interface
> >>> to read conversations and your sent message is included in there
> >>> slotted in where it should be...
> >> I see my own messages both on the GMail Android app as well as
> >> Thunderbird.
> >
> > that's weird... i pull my gmail via pop3 in to my tbird and never get
> > any of my list posts back... i'm on 10+ lists... some with this
> > account and others with my gmail... the gmail account never sends back
> > my messages when i pop them...
>
> I guess that this may be due to your GMail configuration - if you have
> your own messages in GMail moved to folder Sent automatically (even
> though they're not Sent via the GMail UI), those messages may not be
> available for POP3.
>

I use IMAP, so that could also be part of the explanation...

Regards,
Sven

>
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] What makes a Compiler project (like FPC) special?

[Sven Barth via fpc-other]

2017-05-25 21:29 GMT+02:00 Graeme Geldenhuys :
> On 2017-05-25 19:47, Nikolay Nikolov wrote:
> So what is Florian going on about regarding workflow and Git not being able
> to cope in a "compiler" based project? He made it out as if FPC will not be
> workable in a Git managed environment. I don't see his analogy. The Linux
> Kernel running on more platforms than FPC does, is just as complex a beast,
> if not more - considering that the Linux Kernel probably has 10's of
> millions of lines of code, 2000+ contributors. The same could be said for
> the KDE and Qt framework. The latter runs on just about every platform out
> there, as multiple rendering engines, font engines, theme engines, layout
> engines etc.

The workflow of the Linux kernel would simply not be acceptable for us
with them having this hierarchy of maintainers with Linus at the top
and doing all the final merging. If at all an approach like Qt uses
with automatic continous integration of pull requests committed by
core devs or forwarded by them from non-core devs would be the way to
go for us - if at all.

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

[Sven Barth via fpc-other]

2017-05-25 15:34 GMT+02:00 Marco van de Voort <mar...@stack.nl>:
> In our previous episode, Sven Barth via fpc-other said:
>> Of course the biggest obstacle is the building and running of the
>> testsuite.
>
> I think running the testsuite is a waste of time and cycles for anything
> outside compiler/ and rtl/.  And even for half of the RTL.

I essentially agree which is why I wrote in my message to Charlie a
moment ago that the integration system could differentiate here based
on what files were changed.
Though maybe partial testsuite runs would be useful as well, e.g. if
something changed in the rtti unit (which is in the rtl-objpas
package) the tests for that unit/package should at least be run. This
of course would require a few more adjustments to the testsuite, but
it wouldn't be an unsolveable problem.

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

[Sven Barth via fpc-other]

2017-05-25 15:20 GMT+02:00 Karoly Balogh (Charlie/SGR)
:
>> Of course the biggest obstacle is the building and running of the
>> testsuite.
>
> Well. Build breakages are daily occurence with obvious "this could have
> never built" mistakes, or new packages get committed which don't build for
> any platform, etc. Even large patches, with little care and "worksforme"
> excuse. So even in the current system we run the testsuite *AFTER* the
> commits are already made. And lot of the experimental development happens
> in directly trunk. So this reaction of "omg, what happens to the testsuite
> runs" I feel a bit... Yes. :)

I'm aware that the current situation isn't all roses and such (see the
typo you fixed a few days ago: that was me removing a "virtual"
without its semicolon directly before the commit even though I had
already successfully built the compiler previously). So if we had an
automated process to catch such things at least on the Tier 1 systems
you mentioned below that would go a long way already I'd say and - as
you wrote as well - completely independant of SVN or Git.

> And I'm guilty as well, make no mistake. :) But actually this leads us to
> another problem, that now all commits are equal, even if someone touches
> an uncritical/new package or some x86 codegenerator or a critical part of
> the RTL. If the later breaks, could cause problems for everyone years down
> the line, while a package will almost certainly only affect some people.
> Which means different developers work in the same repo with different
> quality/criticality standards...

Maybe such a hypothesized integration system would be a bit more
rigorous depending on what files were changed? E.g. full build with
fullcycle plus testsuite run on Tier 1 targets if anything in compiler
and rtl was changed and only a full build if merely something in
packages was touched.

>> There would of course be the possibility that this would break some
>> target that isn't in the test subset, but let's be honest: that
>> currently happens as well :P
>
> Indeed.
>
> To be honest, I don't see a lot of difference to a Pull request or a diff
> submitted via Mantis. A core developer has to handle both, and sign it
> off. From then on it's his responsibility to handle the patch during its
> lifetime, and revert or fix it, if breaks the build and next days'
> testsuite runs. It's actually pretty much irrelevant if the change got
> into trunk via a manual diff/patch/commit, or someone integrated a pull
> request. What I meant is some automatic process, which makes sure you have
> a linear history suitable for an SVN upstream commit, etc.

I agree.

Maybe we could try at least part of it:
Step 1: have an official FPC trunk Git mirror on our own server with a
mirror/fork of it on GitHub (were those license troubles regarding GPL
and Co I mentioned some months ago solved, btw?) and accept Pull
Requests on the GitHub mirror (those would of course need to be
processed by core devs willing to use Git :P )
Step 2: adjust the Git repo on our own server so that it can react to
Pull Requests from authorized developers (aka us Core devs) as well
and have it do the integration stuff (which of course would require
writing or finding such a system which would be a whole topic in and
on itself) all the while the development process can continue with SVN
as well (without the integration shenigans)
Of course Step 1 would require us to do a conversion from SVN to Git
of at least trunk and to make sure that all revisions that need to be
there are indeed there (e.g. if Graeme's statement is true that Git
ignores commits that only have property changes).

This is of course a rather simplified view of all this and many
problems along the way would need to be solved.

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

[Sven Barth via fpc-other]

2017-05-24 14:12 GMT+02:00 Karoly Balogh (Charlie/SGR)
:
>
> Hi,
>
> On Wed, 24 May 2017, Graeme Geldenhuys wrote:
>
> > If the Free Pascal team is ever serious about migrating to Git, I'll
> > happily help out with the migration process.
>
> Well, I think the resistance is too big for the migration. The SVN people
> go full berserk bloodbath mode when Git is mentioned, and Git people
> usually go "whatever" and just use git-svn. :)

Disclaimer for the remainder of the mail: I've seen Florian's mail
that he currently sees no need to move FPC development to Git,
nevertheless Charlie's mail was too interesting and constructive not
to respond to it :)

> But. If we could come up with a way, which allows accepting pull requests
> with Git somehow (thinking about Github, specifically, but in general),
> then have them seamlessly integrated into upstream SVN as they're
> accepted, that would maybe move things forward. (Remember, we even have an
> FPC organization on Github, which we can utilize.)

The integration of Pull Requests into upstream SVN would indeed need
to be automated as much as possible (I see where Marco is coming
from). In essence those people that currently are allowed to commit to
SVN trunk would be allowed to send a Pull Request to the integration
system (which would automatically do the merge, build and run the
testsuite and commit it to master if successful). If an external
developer would want to see something committed she'd need to send a
Pull Request to one of the Core developers or there would be some
general catch all mechanism in place and some Core developer could
just pick up any pending external Pull Requests and sent it on to the
integration system if deemed worthy of inclusion.

Of course the biggest obstacle is the building and running of the
testsuite. As Florian wrote in one of his other mails we're
partially/primarily relying on build farms that are shared with other
users and on some systems the testsuite run takes long (e.g. on my
PowerBook it takes around an hour). So maybe the Pull Requests for the
integration system could be designed in such a way that only a subset
of the supported targets can be requested for build and testsuite runs
or maybe only a fullcycle is done together with a full build of only
one target all depending on whatever the Pull Request specifies. There
would of course be the possibility that this would break some target
that isn't in the test subset, but let's be honest: that currently
happens as well :P

> With the more automated verifications regarding the integrity of the SVN
> the better. But Marco was right on the point, that this needs a very very
> carefully designed plan and process, to not screw up the upstream SVN.
> Maybe what LLVM and GCC has in place can serve as a starting point.

Qt for example has a similar process (even though they don't have a
SVN master repository anymore like LLVM and GCC do), see here:
http://wiki.qt.io/Qt_Contribution_Guidelines

> And to be honest, I wouldn't even have the full SVN mirror "published" in
> Git, only trunk, and branches fixes_3_0 and newer, with the later being
> read only, as merges would happen by the maintainer, in SVN.
>
> So yeah, TL;DR: instead of trying to fix people we could use engineering
> to make the technology just serve us all. :)

I agree that this could be solved with some engineering if enough
willpower and time (and insight into FPC's development process) is
available.

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

[Sven Barth via fpc-other]

On 23.05.2017 18:00, Karoly Balogh (Charlie/SGR) wrote:
> Also, ever tried to do partial commits in SVN? (Not committing all the
> changes in a single file.) (git add --patch)

To be fair: at least on Windows that is very easy with the help of
TortoiseSVN :)

Regards,
Sven
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other