On Tue, 17 May 2011, Chris Travers wrote:
> For the last few years, LedgerSMB has achieved significant growth.
> Some of that growth has come at an organizational cost and for that I
> apologize to the community. Now I have to try to help put the
> organizational stuff back together.
We had the
Chris,
> Many of you may be frustrated at the pace of development of LedgerSMB
> and the fact that 1.3 has not yet been released. Development may
> appear to have slowed. Public discussions become less frequent...
FWIW, this is normal for projects approaching their first Big Release. The
answe
Hi all;
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...
For the last few years, LedgerSMB has achieved significant growth.
Some of that growth
Jeff Gerritsen wrote:
> I believe a healthy discussion on the future of LSMB is needed, although I'm
> concerned about two issues, one being discussed and one not being discussed!
>
> The concerns I have are about the one issue being discussed may degenerate
> into unproductive language and plat
> Here is my view:
>
> we are far better to stick with one language (probably Perl) for the
> official LedgerSMB core distribution. Eventually, we want an ability
Well one language for core is obviously smart (although I can see some
interesting points for using C in places possibly).
> to eas
Correction:
Gmail messed up my URL:
http://www.ledgersmb.org/community/
On 1/22/07, Chris Travers <[EMAIL PROTECTED]> wrote:
> On 1/22/07, Jeff Gerritsen <[EMAIL PROTECTED]> wrote:
> > I believe a healthy discussion on the future of LSMB is needed, although I'm
> > concerned about two issues, one
On 1/22/07, Jeff Gerritsen <[EMAIL PROTECTED]> wrote:
> I believe a healthy discussion on the future of LSMB is needed, although I'm
> concerned about two issues, one being discussed and one not being discussed!
>
> The concerns I have are about the one issue being discussed may degenerate
> into u
I believe a healthy discussion on the future of LSMB is needed, although I'm
concerned about two issues, one being discussed and one not being discussed!
The concerns I have are about the one issue being discussed may degenerate
into unproductive language and platform wars - although (I believe)
On 1/22/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> Jeff Kowalczyk wrote:
> > --- Chris Travers wrote:
> >> If we rewrite the entire application at once, I am quite afraid it
> >> will never be completed simply because it is such a big task.
> >
> > I agree with this, a rewrite with redesign [
On 1/22/07, Jeff Kowalczyk <[EMAIL PROTECTED]> wrote:
> I agree with this, a rewrite with redesign [1] would take way too long for any
> new or SL user to remain interested in SMB.
>
> > Rewriting in Perl gives us the ability to have a useful application
> > while we are working on it.
>
> What ab
Jeff Kowalczyk wrote:
> --- Chris Travers wrote:
>> If we rewrite the entire application at once, I am quite afraid it
>> will never be completed simply because it is such a big task.
>
> I agree with this, a rewrite with redesign [1] would take way too long for any
> new or SL user to remain inte
--- Chris Travers wrote:
> If we rewrite the entire application at once, I am quite afraid it
> will never be completed simply because it is such a big task.
I agree with this, a rewrite with redesign [1] would take way too long for any
new or SL user to remain interested in SMB.
> Rewriting in P
Chris Travers wrote:
> Every language has the possibility of running into cross-platform
> issues on some level. I have found, for example. that Perl has a few
> Windows issues, but these can be easily worked around. I would expect
> that other scripting languages may run into issues with braind-
Ed W wrote:
>
>>> From a crossplatform point of view I would have thought that Perl
>>> was actually about the best supported tool out there...?
>>>
>>
>> No actually Python or Java is going to give us the best capability there.
>>
>
> It's not really relevant, but I still reckon that Pe
Every language has the possibility of running into cross-platform
issues on some level. I have found, for example. that Perl has a few
Windows issues, but these can be easily worked around. I would expect
that other scripting languages may run into issues with braind-dead
Win32 API behavior too (
From a crossplatform point of view I would have thought that Perl was
actually about the best supported tool out there...?
No actually Python or Java is going to give us the best capability there.
It's not really relevant, but I still reckon that Perl is more widely
supported than
On 1/21/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > Ok, to clarify-- allowing third party add-ons, providing some
> > directional support, etc. happens today. However, these are somewhat
> > limited in scope by the factors described above. I would expect this
>
> And then break compatibi
Chris Travers wrote:
> We have something to gain.
>
> If we rewrite the entire application at once, I am quite afraid it
> will never be completed simply because it is such a big task.
> Rewriting in Perl gives us the ability to have a useful application
> while we are working on it.
I am not rea
We have something to gain.
If we rewrite the entire application at once, I am quite afraid it
will never be completed simply because it is such a big task.
Rewriting in Perl gives us the ability to have a useful application
while we are working on it. I am sure after 2.0, there may be some
cause
Josh Berkus wrote:
> Chris,
>
>> The core application is probably going to remain in Perl for the
>> foreseable future and probably far longer. However, we are working on
>> adding hooks so that additional functionality could be added in other
>> languages. Rewriting the entire application in Py
Just a few thoughts regarding the possibility of add-ons. THese are
just my opinions and no guarantee that we will go this way, and I
reserve the right to change my mind after discussions wiht the
community and other core members
I would really like to see four stable areas for integration:
On Sun, Jan 21, 2007 at 02:41:58PM -0800, Josh Berkus wrote:
> Seneca,
>
> > There is a GL table, it's just that hardly anything uses it, prefering
> > to add up the other tables and storing its values in the acc_trans
> > table. One of my test instances has an entry in it from when I told the
>
Seneca,
> There is a GL table, it's just that hardly anything uses it, prefering
> to add up the other tables and storing its values in the acc_trans
> table. One of my test instances has an entry in it from when I told the
> system that it was the year end.
Right. In a standard accounting data
On Sun, Jan 21, 2007 at 02:01:25PM -0800, Josh Berkus wrote:
> In the realm of general structure, I'm uncomfortable with the fact that SMB
> does not have a GL *table*. While there's nothing innaccurate with doing the
> P&L on the fly by adding up AR and AP, it's both inefficient and does not
>
Chris,
> The core application is probably going to remain in Perl for the
> foreseable future and probably far longer. However, we are working on
> adding hooks so that additional functionality could be added in other
> languages. Rewriting the entire application in Python seems both
> unnecessa
Ed W wrote:
> Chris Travers wrote:
>> Well, here is my sense (not that I am not sure there is a 100% firm
>> concensus).
>>
>> The core application is probably going to remain in Perl for the
>> foreseable future and probably far longer. However, we are working on
>> adding hooks so that addition
Chris Travers wrote:
> Well, here is my sense (not that I am not sure there is a 100% firm
> concensus).
>
> The core application is probably going to remain in Perl for the
> foreseable future and probably far longer. However, we are working on
> adding hooks so that additional functionality cou
Well, here is my sense (not that I am not sure there is a 100% firm concensus).
The core application is probably going to remain in Perl for the
foreseable future and probably far longer. However, we are working on
adding hooks so that additional functionality could be added in other
languages.
--- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Actually (python) has been discussed. At least two of the core members are
> pro python. Python also gives us a better cross platform capability.
That's interesting to hear. For a long while prior to the LedgerSMB fork, I had
considered working wi
GOvvin wrote:
> Do you guys foresee LSMB as staying with Perl or are there plans of porting
> it to a more "maintainable" language such as Python?
Actually this has been discussed. At least two of the core members are
pro python. Python also gives us a better cross platform capability.
That being
Do you guys foresee LSMB as staying with Perl or are there plans of porting
it to a more "maintainable" language such as Python?
Please forgive me if I step on any toes. I am not, in any way, formenting
any language wars. It's just that I have no background in Perl (I'd probably
start learning no
31 matches
Mail list logo
