Recent

Author Topic: What are we missing?  (Read 46555 times)

piGrimm

  • Guest
Re: What are we missing?
« Reply #75 on: October 31, 2017, 08:49:52 pm »
@Mr.Madguy

your writing are just funny since i am PERFECTLY in achordance with Mr. Marcov. (and I suppose, with the laz/fpc DEV TEAM LOL) and I guess that compared to Marcov's knowledge and role, you just are a dancing peanut on the beach of your own nonsense. I do not even read your last cold soup hehehe
T.C.  :P
GOOD BYE
« Last Edit: October 31, 2017, 08:56:33 pm by piGrimm »

mijen67

  • Full Member
  • ***
  • Posts: 130
  • It's hard to beat the bandwidth of a flying DVD
Re: What are we missing?
« Reply #76 on: October 31, 2017, 11:30:31 pm »
The biggest problem, which is a big no for newbies is the documentation. The documentation for FPC is pretty good but the documentation for Lazarus, LCL and other components are disorganized and contain lots of outdated information.

Being a newbie I couldn't agree more.

I often find myself changing search strings from "lazarus <something>" to "delphi <something>" to find useful info.

It should be mentioned that this forum is one of the best programming fora I have ever used and without which I would have given up by now. Thumbs up for this!

Here is my 10c's on documentation.

Documentation has some fine sections here and there, but overall I'm missing a universal structure and it seems there is no minimum requirements for what a section should include to be "sufficient" (correct me if I'm wrong). It also seems a lot of sections in the documentation is something between tutorials and discussions, instead of being brief technical correct descriptions. Tutorials are off course fine but they should be placed under a section called "Tutorials". What I lack more at this time point is briefly formulated technical correct descriptions, backed by a few examples - preferably with a progression in complexity, if possible. There is no single structure that "fits them all", but it's a lot better to decide on a structure and a set of minimum requirements and build documentation around this, than none. These guys http://www.delphibasics.co.uk/RTL.asp?Name=tstringlist have some good ideas on how to put this together. 

Off course, if Lazarus is Delphi <version> compatible an approach could be to point users in that direction, and only document the differences.

However, without a structure/min.requirements for documentation by example package contributors will also have to invent their own structure, and more and more documentation gets build without guidance, minimum requirements, uniformity etc.

Maybe documentation should be split into sections like "Lazarus core", "Lazarus Components (LCL)", ..., Packages (Approved), Packages (not approved), Tutorials, Video tutorials, etc ...  For sure, documentation should focus on being micro-documentation, focusing on each tiny part of the system, and tutorials could be glue that puts "stuff" together to be useful.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: What are we missing?
« Reply #77 on: November 01, 2017, 07:25:01 am »
@Mr.Madguy

your writing are just funny since i am PERFECTLY in achordance with Mr. Marcov. (and I suppose, with the laz/fpc DEV TEAM LOL) and I guess that compared to Marcov's knowledge and role, you just are a dancing peanut on the beach of your own nonsense. I do not even read your last cold soup hehehe
T.C.  :P
GOOD BYE
This thread has "What are we missing?" title for reason. I miss full Delphi compatibility and won't be able to fully migrate to Lazarus till it won't be implemented. Whether some features are good or bad, optimal or not, you personally like them or hate - is out of scope of this thread. Yeah, runtime packages aren't so important, cuz I started to experiment with them just recently, but they would be nice, as I prefer to split my application into plugins (not due to Delphi's limitations, but because I prefer "add new functionality without application rebuild" paradigm) and I hate code duplication, especially if it's such large thing, as LCL. But such things, as Unicode runtime (I need to call API directly very often and all this UTF8->Unicode conversions aren't clear, transparent and reliable enough), full generics support and anonymous routines - are mandatory for me. And if we will continue trying to find excuses instead of actually implementing needed features - we wouldn't have full Delphi compatibility for another 10 years.

If you would stop throwing insults and would finally read, what I suggest, you would find out, that I don't actually ask to switch IDE from source-packages to runtime ones. If Lazarus developers want to keep this paradigm and compiler allows them to link whole bunch of packages into single application (Delphi just can't do it due to 32bit compiler) - then there is nothing bad in it. I ask for at least "Separate package binaries into dynamic library instead of linking them into my application statically" project option. In my opinion this task is trivial. Even I would be able to do it, if FPC/Lazarus sources wouldn't be so messy. And if you would stop finding excuses, why this feature shouldn't be implemented, your would find out, that I also suggest some solutions, that can allow us to beat all cons, runtime packages can have. For example we can implement export via IDs, GUIDs or just pointer tables (as we have information about names in PPUs) instead of using export by name. Yeah, export by name is simple, universal and safe, but it causes extreme inflation of export/import tables. Export via pointer tables isn't so safe, as we have to deal with binary compatibility, but it's much more compact and fast. We can implement optional version or hash check in order to verify binary compatibility for example.

P.S. That's how import table looks like, when you use runtime packages:
Code: [Select]
rtl160.bpl    @System@initialization$qqrv   @System@Finalization$qqrv   @System@TInterfacedObject@_Release$qqsv   @System@TInterfacedObject@_AddRef$qqsv    @System@TInterfacedObject@QueryInterface$qqsrx5_GUIDpv    @System@TInterfacedObject@NewInstance$qqrv    @System@TInterfacedObject@BeforeDestruction$qqrv    @System@TInterfacedObject@AfterConstruction$qqrv    @System@@IntfAddRef$qqrx45System@%DelphiInterface$t17System@IInterface%   @System@@IntfCopy$qqrr45System@%DelphiInterface$t17System@IInterface%x45System@%DelphiInterface$t17System@IInterface%   @System@@IntfClear$qqrr45System@%DelphiInterface$t17System@IInterface%    @System@RegisterModule$qqrp17System@TLibModule    @System@@DynArrayAddRef$qqrpv   @System@@DynArrayAsg$qqrrpvpvt2   @System@@DynArrayClear$qqrrpvpv   @System@@DynArraySetLength$qqrv   @System@@DynArrayHigh$qqrpxv    @System@@DynArrayLength$qqrpxv    @System@@CopyRecord$qqrv    @System@@FinalizeArray$qqrpvt1ui    @System@@FinalizeRecord$qqrpvt1   @System@@InitializeRecord$qqrpvt1   @System@@UStrEqual$qqrv   @System@@UStrCmp$qqrv   @System@@UStrCatN$qqrv    @System@@UStrCat3$qqrr20System@UnicodeStringx20System@UnicodeStringt2   @System@@UStrCat$qqrr20System@UnicodeStringx20System@UnicodeString    @System@@UStrLAsg$qqrr20System@UnicodeStringx20System@UnicodeString   @System@@UStrAsg$qqrr20System@UnicodeStringx20System@UnicodeString    @System@@UStrAddRef$qqrpv   @System@@UStrArrayClr$qqrpvi    @System@@UStrClr$qqrpv    @System@@RunError$qqruc   @System@@Halt0$qqrv   @System@@StartLib$qqrv    @System@@DoneExcept$qqrv    @System@@RaiseExcept$qqrv   @System@@HandleFinally$qqrv   @System@@HandleOnException$qqrv   @System@@BeforeDestruction$qqrp14System@TObjectzc   @System@@AfterConstruction$qqrp14System@TObject   @System@@ClassDestroy$qqrp14System@TObject    @System@@ClassCreate$qqrpvzc    @System@TObject@Dispatch$qqrpv    @System@TObject@BeforeDestruction$qqrv    @System@TObject@AfterConstruction$qqrv    @System@TObject@DefaultHandler$qqrpv    @System@TObject@ToString$qqrv   @System@TObject@SafeCallException$qqrp14System@TObjectpv    @System@TObject@GetHashCode$qqrv    @System@TObject@Equals$qqrp14System@TObject   @System@TObject@Free$qqrv   @System@TObject@$bdtr$qqrv    @System@TObject@$bctr$qqrv    @System@TObject@FreeInstance$qqrv   @System@TObject@NewInstance$qqrv    @System@TObject@ClassName$qqrv    @System@@FillChar$qqrpvic   @System@@AbstractError$qqrv   @System@Move$qqrpxvpvi    @System@IsMemoryManagerSet$qqrv   @System@SetMemoryManager$qqrrx23System@TMemoryManagerEx   @$xp$24System@TInterfacedObject   @System@TInterfacedObject@    @$xp$18System@IEnumerable   @$xp$17System@IInterface    @$xp$14System@TObject   @System@TObject@    @$xp$13System@string    @$xp$7Integer   @$xp$7Boolean kernel32.dll    GetProcAddress    RaiseException    LoadLibraryA    GetLastError    TlsSetValue   TlsGetValue   TlsFree   TlsAlloc    LocalFree   LocalAlloc    FreeLibrary kernel32.dll    GetProcAddress    GetModuleHandleW  borlndmm.dll    @Borlndmm@SysGetMem$qqri  kernel32.dll    GetVersionExW   FreeLibrary rtl160.bpl    @System@Rtlconsts@_SArgumentOutOfRange  rtl160.bpl    @System@Internal@Excutils@initialization$qqrv   @System@Internal@Excutils@Finalization$qqrv rtl160.bpl    @System@Sysutils@initialization$qqrv    @System@Sysutils@Finalization$qqrv    @System@Sysutils@TOSVersion@$bcctr$qqrv   @System@Sysutils@TEncoding@$bcdtr$qqrv    @System@Sysutils@TLanguages@$bcdtr$qqrv   @System@Sysutils@Exception@$bcdtr$qqrv    @System@Sysutils@Exception@$bcctr$qqrv    @System@Sysutils@Exception@$bctr$qqrp20System@TResStringRec   @System@Sysutils@OutOfMemoryError$qqrv    @System@Sysutils@IntToStr$qqri    @System@Sysutils@TOSVersion@$bcdtr$qqrv   @System@Sysutils@TEncoding@$bcctr$qqrv    @System@Sysutils@EArgumentOutOfRangeException@    @System@Sysutils@Exception@   @System@Sysutils@TLanguages@$bcctr$qqrv rtl160.bpl    @System@Math@initialization$qqrv    @System@Math@Finalization$qqrv  rtl160.bpl    @System@Timespan@TTimeSpan@$bcctr$qqrv    @System@Timespan@TTimeSpan@$bcdtr$qqrv  rtl160.bpl    @System@Varutils@initialization$qqrv    @System@Varutils@Finalization$qqrv  rtl160.bpl    @System@Variants@initialization$qqrv    @System@Variants@Finalization$qqrv  rtl160.bpl    @System@Typinfo@initialization$qqrv   @System@Typinfo@Finalization$qqrv rtl160.bpl    @System@Classes@initialization$qqrv   @System@Classes@Finalization$qqrv   @System@Classes@TObserverMapping@$bcdtr$qqrv    @System@Classes@TLoginCredentialService@$bcdtr$qqrv   @System@Classes@TLoginCredentialService@$bcctr$qqrv   @System@Classes@TBinaryWriter@$bcdtr$qqrv   @System@Classes@TThread@$bcdtr$qqrv   @System@Classes@TThread@$bcctr$qqrv   @System@Classes@TBinaryWriter@$bcctr$qqrv   @System@Classes@TObserverMapping@$bcctr$qqrv  rtl160.bpl    @System@Syncobjs@initialization$qqrv    @System@Syncobjs@Finalization$qqrv
« Last Edit: November 01, 2017, 07:47:52 am by Mr.Madguy »
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

Benjiro

  • Guest
Re: What are we missing?
« Reply #78 on: November 02, 2017, 12:08:28 am »
Things that cross my mind and i am going to be brutally honest about this.


Media:

* Naming: Lets be honest, Pascal instantly brings back ( found ) memories of the old programmers but it does not help when topics about Lazarus, FreePascal, Delphi come up in discussions and it instantly turns into "that old language", "nobody uses it", ...

* Dead feeling: Again its about perception. Coming back to Pascal community after 15 years, it feels like there is totally no interest into publicity at all.

Lets look at the freepascal website

February 15th, 2017: FPC version 3.0.2 has been released!
November 25th, 2015: FPC version 3.0.0 has been released!

O yea, now that really gives people confidence that a project is not dead and is pure in maintenance mode. /sarcasm...

* Blog posting? Almost none existing... Its rare to find people blog about why they use FreePascal / Delphi / Lazarus.

* Social Media? Redit / news.ycombinator ... the presence is almost none existing.

r/programming: ... I count something in the order off 11 articles / posts regarding pascal in the last 12 month
r/freepascal ... Graveyard.
r/delphi ... some life but not what you expect for a langue of this size.

lazarus-ide.org has news but it links to forum entries. And it seems it gets very little focus on publication.

* Documentation: Mix between outdated because one keeps finding 10 to 20 year old stuff. And no offense but the:

https://www.freepascal.org/docs.var

If this is anybody there idea of user friendly, modern ... Hello, 1980 wants there html layout back. Color syntax? Code examples ( some do have example but lots do not. And some are so old that they do not work. Seen that with a few )? If i am honest, it does not fill me with confidence.

* Weekly newsletters? Again, no idea if they even exist. What do people even search for?? Pascal, freepascal, delphi, lazarus ... TOOOOO MANY NAMES ... To give you a idea, weekly newsletter delphi = see one that ended in 2007. That again gives the dead feeling.

Codebase:

Location: This is a point that also surprised me. There is no official github for freepascal. I know its at that other place ... even forgot the name, so irrelevant is has become. It feels so old when its not on github ( again my feeling but fairly sure that its also a factor that influences other people )

Bug reporting: Same issue. I HATE languages where they have separated non github bugtracking. I am lazy like a lot of people. If i need to make a account to report a bug on some obscure platform, its already half my interest gone. Yes, that is me but a lot of people are lazy. You lose a lot of people simply because your not using github. Project need to be able to move with the times. Yes, yes, you have valid reason to stay with the other one ( some technical, some simply because some people do not want to modernize / change / move = viewed as stuck in the past ).

Months ago ( one of the reason why i stopped with FreePascal ), i ran into a bug on a Raspberry Pi with Arm compilation. Has that bug been reported? No ... simply because its too much a hassle to figure out where to report, account stuff, ...

Did i mention lazy ( just kidding ) but the real more important factor => The lack of official releases with almost 1 to 2 years in between means a bug that i report, can take years to get fixed into a official build!!!!! And that is NONE ACCEPTABLE!! Sorry for caps but its true. Most people do not want to download and self compile if they can avoid it.

Compiler:

What about more modern compilation outputs. C / C++ have Wasm output. This is the future for web development ( imho ). Even C# with there CoreRT will have wasm. Rust ... has experimental support. Even Nim is talking about it. But pascal, what is almost designed for wasm thanks to the non-gc need?

You want young fresh motivated volunteers to help with that? Well, let us bring up the whole github again...Yea, fat chance that a lot of people are going to help out on anything not git/github hosted. It sounds cruel but that is the world we live in. People need a taste of the good stuff before they get addicted and with so many bridges in the way, it simply demotivates people before they even start.

What i am trying to say is that Pascal is stuck in the past, living too much on its old glory and not moving forwards.

Conclusion:

I can go on for a long time but there is a clear lack of effort. It feels more like everything Pascal related is moving at a snails speed. The people in charge are content and maybe not media aware and hey ... why do we need fancy documentation. Why do we need to publish new features or expected features. Lets release compiler updates every century...

How many people here know about the wonderful OmniPascal plugin for Visual Studio Code? I needed to stumble upon it by accident only to discover there is no publication ( even ended up publishing it around a few times for attention ).

A book can be written about how not to publish a language and the current freepascal / lazarus will be in the top 10. One can blame Borland for the drop in popularity, the moving of the main designer to microsoft but the last 10+ years, sorry but that is mostly homegrown.

As i stated, this is a pure out of my hart comment. I loved pascal in the past and still find it useful today BUT the resources are scattered everywhere, a lot is outdated and difficult to search for with google because of the different naming and overlap, everything feels like its stuck in the 1980s.

The best example of the 1980s stuck is the whole "begin end", what is a joke that shows up every time i published something pascal related. Nobody gives Ruby a hard time with there "end" only but i agree that seeing begin end in some deep loops, can look old fashion.

What freepacal needs in my opinion but will never happen. It is a makeover ... some small syntax changes to modernize, a name that is not associated with constant "old" pascal, a dedicated team that runs a central website where the compiler, lazarus run a combined media portal. Where you have weekly newsletters, updates, twitter and facebook postings, reddit/ynews postings, ... Something to centralize more. And i do not mean the current dedicated lazarus and freepascal websites.

A media offensive where you have people not only post here in this forum but also go out and say: Hey, sure, your language can do x in y seconds. Did you know that freexxxx can do it in y/2 seconds with less memory usage.

Its beyond a few simply fixes if the goal is to make people notice / revival pascal again.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: What are we missing?
« Reply #79 on: November 02, 2017, 01:02:04 am »
Benjiro and others, I must ask you to stop the empty whining. Think, you could have improved the documentation, fixed bugs or do something else useful while writing the horribly long rant.
I know this will escalate like an avalance, more people will join claiming the project's developers try to prevent progress, they don't even want to use GitHub, they work too slowly for us, they are evil ... blah blah blah ...
This is not the first time it happens.
I suggest now that every whiner must somehow improve the issues he is whining about. This is a FOSS project in case you didn't know, done purely by volunteer workers.
If a whiner refuses to work to improve things, he will be banned from this forum. Does it sound reasonable?

This is so stupid. Why would somebody come to a Pascal forum and complain that Pascal has "begin ... end". You can easily find languages that use "{ ... }" instead. Go and use them! Uhhh
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: What are we missing?
« Reply #80 on: November 02, 2017, 03:53:09 am »
Debugger experience is not perfect, true.
I've been on vacation for the past 3 weeks and did some bit of a progress for duby.

It's not much to see, yet.
But I did successfully implemented expression valuation, like:
Code: [Select]
calc(a,b)+calc2(a,b)
where calc() and calc2() are functions in the debugged process, using different calling conventions. (the evaluation is made based on the debugging info available). Needless to say, the expression valuation is expecting pascal syntax.

The biggest challenge was/is actually to create Lazarus-IDE plugin.
The lack of documentation for that is being addressed though.
(please don't point me to GDB plugin... it's 12K lines of code...)
But at this point duby as Lazarus plugin is capable to run,pause and stop the debugged process. Stop at break points, stop and remove them.
Currently working on disassembling (providing some small notes for TCapstone project). And later adding expression valuation support for the plugin as well.

Lot more work to be ahead.

Questions regarding FPC debug information does not get answered here in the forum nor on the mailing list.
ah.. yes, the question.
I guess the assumption is made about the return value approach is the same (for all major calling conventions of i386)
Thus there's no real need to put the extra information for that.

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: What are we missing?
« Reply #81 on: November 02, 2017, 04:37:23 am »
I always try to see thing positively.
Now we've already collected complaints, missing things, suggestions or whatever about the weakness of using Lazarus/FreePascal. How about now we try to make 'real' move to fix them?

The most important things we are lacking now is man power.
Should we now organize some teams to do the certain jobs?
Would you willing to join the teams and spend some of your time?
If your answer is no, then all of this talking is rubbish.

So far I can see the ways to contribute to Lazarus/FPC are limited:
1. Active in this forum to help solving TS' problems
2. Reporting bugs on bug tracker
3. Improving Lazarus/FPC by coding new features and fixing bugs

The no. 4 should be "improving the documentation", but because the wiki pages were written by anyone who want to write, it is not checked by professionals and not organized properly. The result is messy.

If we create some teams and make more possible ways for users to contribute, the progress for improving will be faster. My suggestion are:

- Team A: Helping Newbies In The Forum 
- Team B: Bug Reporting
- Team C: Marketing
- Team D: Documentation
- Team E (not necessary a team): The Developer

Why I suggest forming teams? You know in programming, we have divide and conquer paradigm. By forming teams we can make improvements easier.

Team A will always greets new members in this forum and help them by supplying reading materials, code, etc. Team B will focus on bug reporting, if someone found bugs then Team B will test to code and  submit it to the bug tracker forum, he/she will monitors the bug fixing progress and reporting back to the forum if it has solved. Team C will do lots of thing to publicize Lazarus/FPC similar to what Benjoro said (blog posting, social media, news letter, info on Lazarus/FPC official website and others). Team D, well you know - they try to make documentations and wiki pages better.

Every team should have several members, more members is better because the tasks aren't simple. And each team must have a team leader. Should we start to build teams now? Or do we still complaining without taking any real action?

About the modernize the language. People suggesting this usually forget the compatibility issue. For example if for-end without begin, I hate it >:(
Not because I hate the new construct but my 10 years old code can't compile. And please don't suggest new compile mode, it is confusing especially for newbies. So for everyone who want to suggest new language construct, please think first about code compatibility.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: What are we missing?
« Reply #82 on: November 02, 2017, 07:09:57 am »
The most important things we are lacking now is man power.
Should we now organize some teams to do the certain jobs?
Would you willing to join the teams and spend some of your time?
If your answer is no, then all of this talking is rubbish.
I fully understand, that Open Source concept is "perfect" in theory only and in reality it's about "If you want anything to be implemented or fixed - do it yourself". I wanted to help with implementation of anonymous routines, cuz I really need them - all my test cases use them. It isn't that hard in theory - I just need to turn anonymous routines into interface methods and "capture" local variables, i.e. store them in this interface instead of storing them in stack. So, it's all about macro-programming, i.e. replacing one code with another. But FPC's code has very low quality, i.e. structured way too poorly, so it's really hard to understand anything there. Where are interfaces implemented? Where are local variables handled? How can I modify all this stuff without breaking anything? I asked for help on forums - nobody helped me. "Somebody is already doing it - it should be in one of next releases" they answered. But when will he finish his work? And will he finish it at all? We don't know. So I decided - ok, there is dedicated team, that knows how to do it and is very experienced - let's just wait for next release.
« Last Edit: November 02, 2017, 07:14:16 am by Mr.Madguy »
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: What are we missing?
« Reply #83 on: November 02, 2017, 09:27:50 am »
Glad to hear that you want to help to implement the new features. I ever tried to pick and solve some random bugs in the bug tracker forum, but I just not skilled enough to do so.

As far as I know this forum is for general questions and helping newbies. If you're interested in developing Lazarus/FPC you should join the developer mailing lists:
https://www.freepascal.org/maillist.var

And here I found some links that maybe useful for you:
http://wiki.freepascal.org/How_to_become_Lazarus_developer_%28committer%29
http://wiki.freepascal.org/User_Changes_Trunk
https://www.freepascal.org/future.var

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: What are we missing?
« Reply #84 on: November 02, 2017, 11:01:39 am »
Documentation is a problem. It needs somebody to take the challenge and do it. It is that simple!
Wiki has its inherent problems and limitations. It cannot be the only documentation.
LCL documentation could easily be improved now by using the nice FPDoc Editor which is integrated in the IDE. Patches are welcome.
IDE internals could be documented with it, too, but it is not done yet. Challenge, anyone?
Sky is the limit for somebody who truly desides to improve things instead of whining here ...

In general a "developer" is somebody who implemented and improved things that needed to be implemented and improved.
Simple, ha?
Then he has passed an edge after which there are no ready answers. The answers must be digged up or created.
It feels counter-intuitive that those people get the blame for doing poor job or working too slowly. There are many people who didn't do anything, why don't they get the blame?
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

minesadorada

  • Sr. Member
  • ****
  • Posts: 452
  • Retired
Re: What are we missing?
« Reply #85 on: November 02, 2017, 11:48:32 am »
It can be difficult for an average developer to contribute to the project if they don't have access to many environments for testing.   The multi-platform ability of FPC/Laz is both a boon and a bane.
Even covering the main 3 (Windows, Linux and Mac) involves a complicated (and expensive) development setup.

Cloud/web-based languages and JIT meta-languages are much easier to manage, bugfix and improve I would imagine.

[One codebase / many platforms] -> Native binary is an amazing achievement by the fpc/laz developers and is not to be underestimated.

@JuhaManninen: Sometimes it is "undocumentation" that is the problem.  Take file handling as a typical example:  There is loads of documentation on old file functions like Reset/Rewrite/IOResult etc, which was supplanted by FileRead/FileWrite etc, which was supplanted by FileStream and other streaming stuff.   It is a risky job to rewrite/revise/delete old documentation so few people do it.   Consequently, folk go to the wiki or elsewhere to learn how to handle files in FPC/Laz; come across the old TP stuff and conclude that Lazarus belongs in the 1990's.  Would it be the "right thing" to delete all references to TP-style filehandling?  Some programmers like to know 3 ways of doing the same thing; other programmers (especially beginners) simply want the best and most up-to-date way.  No-one likes to delete documentation (undocument!) but maybe it's needed as the language evolves. 
Summary: New features are usually documented, but obselete features are rarely undocumented.
A worthy project for a masochist :) might be to make a new wiki, "undocumenting" all the historical crap that confuses people.

I would agree that good documentation not only makes or breaks the maintainability of any code (in any language), but is also super-important for any language that hopes to make an impact on new-generation programmers. Lazarus will live or die based on clear and simple help and examples being produced as it evolves.

Documentation aside, this year there have been two great contributions to the project by @DonAlfredo and @Getmem.  I am referring to fpcupdeluxe and OnlinePackageManager of course.  They address the issues of multiplatform installation/cross-compilation/updating and 3rd-party component organisation respectively.  This has been a leap forward for the Lazarus project facing newcomers IMHO.

In terms of recent language improvements, surely the efforts to rationalize strings (and explain them, @JuhaManninen!) and the work on generics have to be highlights.

My 2€
« Last Edit: November 02, 2017, 12:50:49 pm by minesadorada »
GPL Apps: Health MonitorRetro Ski Run
OnlinePackageManager Components: LazAutoUpdate, LongTimer, PoweredBy, ScrollText, PlaySound, CryptINI

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: What are we missing?
« Reply #86 on: November 02, 2017, 03:04:43 pm »
It can be difficult for an average developer to contribute to the project if they don't have access to many environments for testing.   The multi-platform ability of FPC/Laz is both a boon and a bane.
Even covering the main 3 (Windows, Linux and Mac) involves a complicated (and expensive) development setup.
I develop mostly on Linux using LCL GTK2 and QT bindings, and sometimes on Windows. Obviously I cannot create Mac specific code myself but I have had enough to do without it.
So it is not difficult! Sounds like an excuse.

Quote
Sometimes it is "undocumentation" that is the problem.
Yes. Could you please take it as your duty to "undocument" obsolete stuff.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

J-G

  • Hero Member
  • *****
  • Posts: 953
Re: What are we missing?
« Reply #87 on: November 02, 2017, 04:40:51 pm »
Quote
Sometimes it is "undocumentation" that is the problem.
Yes. Could you please take it as your duty to "undocument" obsolete stuff.

Aaaaarrrrr!!  >:D   Please don't !  Just because it is 'old' doesn't mean that it is obsolete and useless.

Would you countenance the destruction of library books just because they were 'old' ?

FPC 3.0.0 - Lazarus 1.6 &
FPC 3.2.2  - Lazarus 2.2.0 
Win 7 Ult 64

Benjiro

  • Guest
Re: What are we missing?
« Reply #88 on: November 02, 2017, 05:53:51 pm »
This is so stupid. Why would somebody come to a Pascal forum and complain that Pascal has "begin ... end". You can easily find languages that use "{ ... }" instead. Go and use them! Uhhh

I was referring to the fact that from a public point of view, it bothers people. Given the comments that keeps laughing about it. So again, i am not the one complaining only relaying the responses that i have seen when Pascal get mentioning. The whole double function naming ( what is nothing more then c its .h + .c files combined into one .pas file ), is also one of those points people "complain" about. That is why Pascal is stuck in the past. Never hear about external function declaration? Its again one of those things that i personally hear people complain about. Same with the way class support is kind of forced into the language.

And they have valid points on some of them. I can not help it if people grip about that. There is no counter arguing base language features. I tried and lost that battle too many time now.

Benjiro and others, I must ask you to stop the empty whining. Think, you could have improved the documentation, fixed bugs or do something else useful while writing the horribly long rant.
I know this will escalate like an avalance, more people will join claiming the project's developers try to prevent progress, they don't even want to use GitHub, they work too slowly for us, they are evil ... blah blah blah ...
This is not the first time it happens.
I suggest now that every whiner must somehow improve the issues he is whining about. This is a FOSS project in case you didn't know, done purely by volunteer workers.

Its a excuse that i hear on every FOSS project. There is always time to put out new features but for some reason actually attention to the public profile / media attention / impression of the language, is for so many open source projects a issue. As the people who "whine" are considered bad for not putting in time. But those that do put in there time, keep forgetting its not all about new features.

Seeing as my whining has been about 1 post in all this time, so excuse me for taking it personal.

If a whiner refuses to work to improve things, he will be banned from this forum. Does it sound reasonable?

Well, with that attitude ... you have my full attention. People in a higher position that can not see that this whining comes from a long time problem that Pascal is facing. I do not need to repeat the points how badly the media exposure of pascal is. I can see the issue but i am not the guy to fix them. There is no point on putting people on tasks when they are not qualified for them. Plenty of other things on my plate. Lean the difference between whining and pointing out issues in one post. They are not the same.

I am tired to deal with FOSS project where any comments is considered whining when its my only freaking post on the topic and where i spend a LOT of time trying to identify the issues. But hey, seeing as you consider it whining and useless. Its like working for a company where you tell the boss, we are driving towards a cliff and you get blamed for mentioning it. And then years later, the company goes belly up. Yea ... I have a LOT of experience with failing projects and companies because of this type of attitude.

People whine too much here? I do not personally know but going by your response your fed up with people whining. Well, if there are so many whiners, that means for a long time you have been doing things wrong. Self reflection guys!

/Self reflection: Never put time into established FOSS projects, its always the same.

For your information, i was the guy putting up news topic regarding OmniPascal and others tidbits on reddit and other locations. But as you state, whiner ... so ... i welcome the ban.

You have my "whine" post that identifies plenty of the issues.

Solve it yourself ungrateful ******. This is my last comment here. Ever!

piGrimm

  • Guest
Re: What are we missing?
« Reply #89 on: November 02, 2017, 07:34:07 pm »
well,
as I did write CLEARLY the reasons (concepts) why packages (BPL = Borland Packed LIBRARIES) can NOT easily be ported onto FPC because of its multiplatform UNIVERSAL constraints, I got flamed and kind attacked. No matter, I know what i am talking about, and @marcov too, apparently  :)
Finally, I agree with the WHOLE Laz Team and devs (moderators here), meaning if all people whining could STOP; and then try to spend their whining time to contribute...
... when something do not work the way they want, "simply" (LOL Mr. Madguy) learn the sources and propose their patches, and own sources, the projects (laz + fpc) might then not be stuck in the tears lake of these people, for years!
ENJOY!
« Last Edit: November 02, 2017, 07:40:06 pm by piGrimm »

 

TinyPortal © 2005-2018