Re: [Lazarus] EpikTimer v1.0.1 released
On Mon, May 26, 2014 at 3:38 AM, Michael Schnell mschn...@lumino.de wrote: I use EpikTimer in my (soon to be released) work on the ActiveNoGUI Widget Type. Here I found, that it is a rather appropriate use for EpikTimer to handle it in a static way, not creating an instance of TEpikTimer with every use of same, but simply to use class properties, class procedures and class functions of TEpikTimer. The advantage of this is that the overhead when creating an EpikTimer is reduced to zero. Hi Michael, I'm having a little trouble understanding where new functionality is needed for your use case. With the existing code, you don't need to create an EpikTimer instance each time you need a new timer. A single instance supports an unlimited number of timers using the TimerData record from the EpikTimer unit: TimerData = record Running:Boolean; // Timer is currently running TimebaseUsed:TimeBaseSelector; // keeps timer aligned with the source that started it. StartTime:TickType; // Ticks sample when timer was started TotalTicks:TickType; // Total ticks... for snapshotting and pausing end; You can declare any number these records to create as many timers as you need. Here's an example for a single ET instance of EpikTimer: Function TimedExecution: Extended; Var i:integer; TimerA,TimerB:TimerData; TickTick:Array[1..1000] of TimerData; // if you need a thousand timers Begin ET.Clear(TimerA); ET.Clear(TimerB); // Declared timers must be cleared before use For i:=1 to 1000 do ET.Clear(TickTick[i]); ET.Start(TickTick[someindex]) ET.Start(TimerA); ExecuteTimedSectionA; ET.Stop (TimerA); ET.Start(TimerB); ExecuteTimedSectionB; ET.Stop (TimerB); ET.Stop(TickTick[someindex]) etc... The mechanism is pretty efficient as the record for each timer is only a few dozen bytes. One instance is necessary to do the initialization that detects the available timebases and does a rough overhead calibration for system calls. There's always going to be edge jitter with userland calls, so calibrating each timer wouldn't add certainty to the overall measurement. If I'm not understanding the problem you're trying to solve, could you please explain it a little further? Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to program with time in milliseconds?
On Mon, May 19, 2014 at 11:54 AM, Graeme Geldenhuys mailingli...@geldenhuys.co.uk wrote: On 2014-05-19 11:03, Michael Schnell wrote: Obviously I can't _use_ EpricTimer there, as it uses (IMHO inappropriately) (graphics-) stuff that is not implemented in a non-GUI project. You are clearly using a very outdated version. That was fixed 2+ years ago. Get the latest code from SubVersion instead of the ZIP download. There's no question that the component needs an update as the current zip on the Lazarus-ccr was packaged in 2006. SVN is more current and Graeme and I will get together and roll any additional improvements he's made into a new release. If we need to make improvements to the core measurement routines for better cross platform support, some additional input would be helpful. For hardware timing, I see the following support across processor types: http://en.wikipedia.org/wiki/Hardware_performance_counter There is a Performance API (PAPI) standard for cross platform access to those counters, but probably not a candidate as it requires OS support. Regarding OS based timing, my experience is limited to Linux and Intel/AMD, so if there's a more universal approach, I'd be very interested in learning more about it. Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to program with time in milliseconds?
Tom and I would welcome patches for EpikTimer. Maybe EpikTimer should move to the Git repo of Lazarus-CCR so others could easily clone and share their feature branches (say via Github). Fully agree... great idea! -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to program with time in milliseconds?
On Sun, May 18, 2014 at 12:17 PM, Graeme Geldenhuys mailingli...@geldenhuys.co.uk wrote: On 2014-05-18 00:49, Tom Lisjac wrote: I'm adding some clarification and context to your ongoing comments about EpikTimer in this and other threads. Tom, as I have mentioned in this thread, I have some improvements in my local copy of EpikTimer, which oddly I haven't shared with the community. I'll create a patch set and pass it on to whomever maintains EpikTimer (in Lazarus-CCR I believe?). Hi Graeme, I remember you mentioned making some improvements and it would be great to include them in a new release. The demo program is compiling again thanks to some much appreciated help from the list last week. Also installed Lazarus on the Raspberry Pi to see if EpikTimer has any issues on ARM. If so, I'd like to get them resolved before we post an updated zip on the Lazarus-CCR. Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to program with time in milliseconds?
Dear Mr. Michael Van Canneyt,
I'm adding some clarification and context to your ongoing comments about
EpikTimer in this and other threads.
Snip EpikTimer code
Why you would not use fpnanosleep on CPUX86_64 as well is a mystery to
me...
There's no mystery here. I wrote EpikTimer in 2003 with a few months of
experience on a 32 bit version of Lazarus. The code still works, but a lot
has changed around it over the last 11 years.
Epiktimer is probably the most overrated component on lazarus-ccr. No
idea why people still recommend it, unless I missed something :(
No mystery here either. You never miss an opportunity to criticize
EpikTimer for reasons I've never been able to understand.
If there's another component or technique that does this better, can you
please recommend it rather then relentlessly criticizing the one I
contributed?
Of course in the end I need something that works for any CPU and OS.
There is nothing. EpikTimer pretends to fill this gap, but it does not.
Don't get me wrong: I have nothing against the epiktimer, but it is
presented as some super cross-platform solution (or so I perceive it).
To clarify, EpikTimer was created in 2003 to help simplify the measurement
of elapsed time. It used the x86 TSC hardware, if available and reverted to
the system clock if it wasn't. I needed this capability and thought others
might as well. My original version was documented to only work on 32 bit
Linux and was never presented as a super cross-platform solution. Over
the years other contributors modified it for Windows and 64 bit operation.
Epiktimer was written during the early days of the Lazarus project when
cross platform capability was an evolving dream and the IDE was just
starting to be stable on Linux. The code is 11 years old, but despite it's
age, EpikTimer still works well, is downloaded many times per week and
actively used across a variety of projects. It could use an update and
re-release that I was starting to work on but at this point I've lost my
enthusiasm to complete it.
-Tom
On Mon, May 12, 2014 at 7:57 AM, Michael Van Canneyt mich...@freepascal.org
wrote:
On Mon, 12 May 2014, Reinier Olislagers wrote:
On 12/05/2014 13:32, Michael Schnell wrote:
On 05/11/2014 09:44 AM, Graeme Geldenhuys wrote:
Take a look at EpikTimer. It uses hardware timers where available, with
an easy to use API for the developer.
IO took a look.
Seemingly this is only available for X86 and X86_64.
How did you get that idea? The wiki page even explicitly mentions ARM.
Yes, it WORKS on arm.
But on all systems except i386, you can just as well use Now() and
Sleep(), because that is what epiktimer uses:
(sources quoted from the lazarus-ccr repository)
function SystemTicks: TickType;
{$IFDEF Windows}
begin
QueryPerformanceCounter(Result);
{$ELSE}
var t : timeval;
begin
fpgettimeofday(@t,nil);
Result := (TickType(t.tv_sec) * 100) + t.tv_usec;
{$ENDIF}
and
function TEpikTimer.SystemSleep(Milliseconds: Integer):Integer;
{$IFDEF Windows}
begin
Sleep(Milliseconds);
Result := 0;
end;
{$ELSE}
{$IFDEF CPUX86_64}
begin
Sleep(Milliseconds);
Result := 0;
end;
{$ELSE}
var
timerequested, timeremaining: timespec;
begin
timerequested.tv_sec:=Milliseconds div 1000;
timerequested.tv_nsec:=(Milliseconds mod 1000) * 100;
Result := fpnanosleep(@timerequested, @timeremaining) // returns 0 if ok
end;
{$ENDIF}
{$ENDIF}
Why you would not use fpnanosleep on CPUX86_64 as well is a mystery to
me...
Epiktimer is probably the most overrated component on lazarus-ccr. No idea
why people still recommend it, unless I missed something :(
Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] int64 assignment fails
That was it... many thanks to you and Flavio! -Tom On Sat, May 10, 2014 at 11:41 PM, leledumbo leledumbo_c...@yahoo.co.idwrote: http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-int64-assignment-fails-tp4036884p4036887.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] int64 assignment fails
fpc-2.6.4-1.x86_64. says Argument can't be assigned to when trying to compile the following: type TickType = Int64; TimebaseData = record TicksFrequency: TickType; end; TEpikTimer= class(TComponent) private FHWTicks:TimeBaseData; Public property HWTimebase: TimeBaseData read FHWTicks write FHWTicks; TForm1 = class(TForm); public ET:TEpikTimer; procedure TForm1.Button8CLICK(Sender: TObject); begin ET.HWTimebase.TicksFrequency:=10; // Fails This used to compile and seems like a straightforward int64 assignment. Has something changed where this is no longer allowed? Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Tue, Mar 9, 2010 at 1:38 AM, Vincent Snijders vsnijd...@vodafonevast.nl wrote: Alexander Klenin schreef: On Tue, Mar 9, 2010 at 13:44, Hans-Peter Diettrich drdiettri...@aol.com wrote: It's not so simple. Guess why it took me more than a year to implement usable docking - it's not a matter of implementation, but a matter of discussions what is *allowed* to change in a poor interface, and what additional LCL/Delphi incompatibilities already have been introduced and must be respected by all new code. It's almost impossible to replace an inappropriate implementation by a better model, because some existing code *could* be broken by such an change - unless such a suggestion comes from a core developer, who simply changes his existing code. I wholeheartedly agree with the above -- a purely theoretical backwards incompatibility issue already prevented me from contributing to at least one Lazarus subsystem. I wonder how such wishes can be reconciled with wishes from Tom Lisjac for example to have more stable lazarus, not changing compatibility every release (if that is what actually happens). I don't remember suggesting that compatibility should never change between major releases. What we've been talking about in this thread is for stability issues to *start* being considered and to *begin* managing changes so version impacts on production developers and existing code would be minimized or at least well documented. Borland always did this with new version releases, so when they made changes, the community understood and was fully prepared for them. The stability issue occurs when arbitrary changes are tossed in randomly and without regard for their impact existing code... and with no documentation. This doesn't mean that there has to be total compatibility between a version 1.0 and 2.0 if necessary changes and their impact on existing code are clearly documented. It also won't be an easy or straightforward process managing codebreaking decisions because there will always be genuinely good reasons to make changes... but starting the process of managing code impacting changes is an essential next step if there's ever going to be a credible 1.0, 2.0, 3.0... etc for this project. This thread was simply intended to flag a real world problem that developers are having when trying to create production code with this tool. Many of us were hoping to see a civil discussion of that topic that might have even lead to finding a mutually agreeable solution. I'm sorry that didn't happen but I'm hoping it will at a later time... and definitely before a serious effort is made to release a 1.0. -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Tue, Mar 9, 2010 at 2:30 AM, Florian Klaempfl flor...@freepascal.org wrote: Rigel Rig schrieb: Until then, do not be surprised why there are not many new programmers Luckily enough we heard the same for FPC and experience showed that 1.0 didn't change anything regarding contributors. So this argument is simply nonsense. When the 1.0 compiler came out, Delphi was cheap, worked well and dominated the market. At the time, mainstream Pascal developers had no reason to care about that other compiler or volunteer to support it. ... but how times have changed! :) It's a totally different landscape now, Florian... and it's completely flawed to compare the lack of motivation for volunteers with the 1.0 compiler to the current situation with Lazarus. -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
It's a matter of the glass being half-empty or half-full. Graeme currently sees a half-empty glass. I think the point of these threads is not how one views a partially filled glass... but that it remains in a partial state year after year with no clear goal to ever make it full. A Lazarus 1.0 would go a long way toward filling the glass, but it's only half of the equation. To provide a stable and production ready platform, the compiler developers must also commit to respecting developer codebases and not breaking them with frivolous language changes... otherwise even with a Lazarus 1.0, the glass will remain clouded and one that large scale and commercial developers will continue to avoid drinking from. Tools are judged by what they have built... not on their potential. Frustration sometimes bubbles up on these threads because the potential is there... and the potential is great! No other open source tool of comparable power exists for generating light, fast, self contained and cross-platform graphical apps with an equally fast and full featured IDE. Given the bloated or proprietary alternatives, Lazarus/FPC should be the tool of choice for creating world class apps for all the major OS environments... but as Graeme accurately pointed out, what we have today is still potential. The only thing that is stopping Lazarus/FPC from become a stable, mainstream production tool is attitudes... and I'm hoping threads like these will cause a change of focus across the core teams from feature development to stabilize what we have and to release 1.0 as Paul Ishenin suggested yesterday. Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Fri, Mar 5, 2010 at 8:47 PM, Paul Ishenin webpi...@mail.ru wrote: My current goal is to stabilize what we have and to release 1.0. For a project goal, it would be hard to top that one for conciseness and clarity of purpose... well said, Paul! Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] ZVDateTimeControls Package available on Lazarus-ccr
Zoran Vučenović has created a full featured, cross-platform time/date picker component along with a data aware version. It's available on the Lazarus-ccr under a new Time and Date folder or via this direct download link: http://sourceforge.net/projects/lazarus-ccr/files/Time%20and%20Date/ZVDateTimeControls%20Pack/ZVDateTimeCtrls.zip/download Documentation for the component set can be found here: http://wiki.lazarus.freepascal.org/ZVDateTimeControls_Package Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release 1.0, part 2
On Sun, Nov 29, 2009 at 2:28 AM, Marco van de Voort mar...@stack.nl wrote: On Sat, Nov 28, 2009 at 09:14:52PM -0700, Tom Lisjac wrote: The problem I see is credibility... or if we write a lot of code with Lazarus/FPC, will it be maintainable with the project in perpetual beta?. Personally I think this discussion is funny, weeks before 2.4.0 comes out and lazarus faces a transition to a new resources system. Of course technology evolves and changes will need to be introduced over time... the problem is that better version control needs to start now so pure app coders won't have to be in the development loop on a daily basis to keep up. In the current beta model, changes are added on the fly and anyone developing code has to follow the development track on an almost daily basis to keep their code working. This isn't realistic for a wider audience that just wants to use the tool to write apps and have confidence that they'll be able to compile them next year without having to review all the development threads and changes that took place in between. Formalizing a 1.0 would establish a well defined baseline and make it possible to provide release notes that describe exactly what aspects of the 1.0 code would be impacted when moving to version 2, 3, 4, etc. On the other hand, if the project keeps wandering around in a beta state where changes continue to be introduced on the fly, all the code that's currently out there will continue to become more and more broken with each passing day without a clear path for getting it fixed. Anyway, if I have to choose between credibility for Delphi users searching for a quick fix, and the more deeply committed serious contributing users, I know which I choose. The serious users will consider the current restrained version policy as more serious and see through a cheap spin. I would agree if I believed that Lazarus/FPC had any serious users. Other then the core development team, their employers and people who closely follow the development track, who is using this toolchain for deploying serious public or commercial work? That wasn't a frivolous question and if such a listing exists, I'd be very interested in seeing it and noting its length. Here in the US, doing a search on hotjobs.com for Lazarus returns Sorry, we didn't find any Lazarus jobs. A search for Delphi returns a total of 17 nationwide whereas Java returns 2,817, C# 1,159 and Linux 1,817. Delphi is already a relic in the US, but with changes, I hope there's still a future for Lazarus/FPC as a serious commercial tool. In another part of this thread someone pointed out that more developers are needed then users. I disagree. From my perspective, the Linux kernel again provides a useful model for a successful project that started with one guy. Once the kernel had achieved critical mass on a technical level (meaning it basically worked), Linus was able to sell a bunch of other people on trying it out... and some of those people were developers. What happened next is part of history. Lazarus has had critical mass for a long time. Even in 2002 I found it to be a very capable and stable tool and I thoroughly enjoyed working with it. In it's current state it is nothing short of awesome! What is needed now is to get more people actually looking at it... and if we can achieve that higher visibility and enthusiasm within the larger community, some of those new users will be developers. Where the days of Delphi are fading, the story of Lazarus is still evolving. At this point I see it as a developer's project that has been almost ready for wider use for far too many years. It's true that 1.0 is just a number... but it is the one that will clearly signal our critical mass and hopefully be the trigger that will start moving this great tool into the programming mainstream... and the job market. Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release 1.0, part 2
Hi Florian, On Sun, Nov 29, 2009 at 2:12 AM, Florian Klaempfl flor...@freepascal.org wrote: Tom Lisjac schrieb: To compare, Linux is now running corporate datacenters around the world... and Lazarus is still in beta with very few public applications deployed. The same might be applied to delphi too: it appears that there are few public applications deployed. Given it's relatively brief life, there are actually quite a few well known applications, including Skype, TOAD, Altium Designer, The Bat!,...etc that were built with Delphi: http://delphi.wikia.com/wiki/Good_Quality_Applications_Built_With_Delphi Sourceforge currently hosts 3,170 Delphi/Kylix related projects while Torry's and DSP also list thousands of Delphi related applications and packages. In contrast, the lazarus-ccr has 56 packages at last count and Sourceforge shows 124 Lazarus and 432 Pascal projects. These small numbers provide an alarming perspective on the total Lazarus/FPC mindshare as Sourceforge also hosts 20,313 projects for Java, 14,645 for php, 13,987 for C#/C++, 5,208 for Python and even 2,030 just for the Eclipse ide. source level past the version 1.0 release that will hopefully be shared by the FPC team. When did FPC break source level stuff not being a bug fix? During this time last year, I was working on a large project that I intended to deploy to several thousand users within my company. The compiler/ide was working great, but I was also tracking the compiler svn to make sure I didn't get into creeping features trouble that might break the project and cause maintenance issues downstream. Sure enough, sometime during the Nov/Dec 2008 timeframe I got a compile error with the new version. I don't remember the details but found a small posting explaining that this was due to a permanent change in the scoping of inherited class variables in this and future compiler versions. I will have to un-archive the project to provide the specifics, but I remember having to move some variables out of either private or protected and exposing them more globally to get my application to compile. Regardless of the specifics, this was a change to the language within 2.x that broke my code at the source level. Changing the scope of a variable in post production would have also triggered a QA review and unwanted visibility for using beta software... so I decided to put the idea on hold and wait another year to see if Lazarus and FPC would come together at 1.0 and become a unified, non-experimental tool that I could rely on for production coding. That year has passed and here we are. With all that I've said over the last few days, I sincerely hope that you and the other developers have not interpreted any of my comments as criticism. The accomplishments of the compiler and IDE teams have been both inspiring and spectacular! But at this point, I think it's time to revisit some prevailing attitudes and make a few adjustments. In short, after over a decade of brilliant, creative work, it's time to stop pushing back on the idea of a 1.0 for Lazarus/FPC and to rally behind the goals of production stability for application builders and promoting a wider utilization for this outstanding tool while the window of opportunity for it still exists. Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Release 1.0, part 2
So what exactly is the Lazarus team afraid of in getting to v1.0? Since we think it's not ready for 1.0. Period. The above comment seems to have stopped the previous Version 1.0 thread so I'm starting a new one with the hopes of hearing some additional comments and suggestions for achieving this goal. Of course the core compiler and ide development teams have done an awesome job over the many years that this project has been in process, but *many* others have also contributed their time and energy along the way and have an interest in seeing this project achieve a 1.0 release. Personally, I'd like to see Lazarus and FPC start to move forward and get the respect and larger following that they deserve... but with it's history and stalled 1.0, I don't blame any noob, experienced developer or business that makes an informed decision to avoid this toolchain. The problem I see is credibility... or if we write a lot of code with Lazarus/FPC, will it be maintainable with the project in perpetual beta?. Delphi was stable from release 2 and code I developed with it in versions 2, 3, 4 and 5 continued to just work as I upgraded. Not the case here. I've been writing new code with Lazarus since 2002 and have learned that anything I write today is virtually guaranteed to be broken and uncompilable tomorrow because somebody thought it would be cool to change some aspect of the Object Pascal language or completely revise a library interface or function. It's become a lot of work to maintain the stuff I've already written and I'm reluctantly considering not using Lazarus for any new projects. Businesses laugh in our general direction over the code breakage issue where a project investment using Lazarus/FPC may end up a QA and maintenance nightmare. This view is shared by many of my colleagues who can't understand why I'm still using a beta ide on a dinosaur language from the 80's. How's that for an insult? I agree with Graeme's posting that this has become a public relations issue... an obvious one. I'm also starting to see it as a squandered opportunity to displace the bloated languages on the Linux platform where fast, compact and self contained Lazarus apps should be a dominant presence right now... today. Yes, Lazarus is an open source project, people work on it for fun and there is no business entity that is promoting it. Lazarus has been active for around 10 years and FPC even longer then that. The Linux OS also started to emerge during this same timeframe with the same type of development model. To compare, Linux is now running corporate datacenters around the world... and Lazarus is still in beta with very few public applications deployed. I don't think a case can be made that the project isn't ready for 1.0... after 10 years of development and it's current, impressive state, of course it is. The next steps are to actively discuss the finer points of what ready is and to set a definite goal to achieve it. As I see it, this will involve a feature set freeze, establishing bug thresholds *and* making a reasonably sincere commitment to not break compatibility at the source level past the version 1.0 release that will hopefully be shared by the FPC team. A version 1.0 milestone is crucial and much more then a given feature set and minimized bug list. It also conveys the idea of stability and confidence to anyone who may be interested in investing their time to learn the language, use the tools and create something of lasting value. If we don't start building that confidence in the larger community pretty soon, this project will continue to be viewed as a toy and will eventually become a relic to a once great development paradigm. Thanks, -Tom -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] FileMenuHandler and bzip2lib packages available on the Lazarus-ccr
Juha Manninen has converted a streaming library wrapper for bzip2 and a FileMenuHandler component for use with Lazarus. Documentation pages have been added to the Lazarus wiki and the packages are now available for download: http://sourceforge.net/projects/lazarus-ccr/files/FileMenuHandler/FileMenuHandler.tar.gz/download http://sourceforge.net/projects/lazarus-ccr/files/bzip2lib/bzip2lib.tar.gz/download The documentation for these packages can be found here: http://wiki.lazarus.freepascal.org/FileMenuHandler http://wiki.lazarus.freepascal.org/bzip2lib Thanks Juha! -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
