2009/12/11 Adrea Lund :
> Thank you for all the responses. I should have explained more clearly that
> I know extremely little about mysql - so some of the comments I've gotten
> from the lists I sent this to are going right over my head. But I do
> promise that once we have a working report(s),
NoZebra mode is at a severe disadvantage in terms of featureset,
performance, scalability, extensibility and basically everything (except
ease of installation). I would not recommend that anyone who wants their
feature to be used by even modestly sized libraries should develop it for
NoZebra mode.
2009/12/11 Kyle Hall :
> I've always wondered why the developer meetings to place on #koha. It
> seems logical to me to have them take place in #developer-meeting or
> something similar. The meetings would still be open to all, but people
> not interested in the meeting would not interrupt it by ac
Ian,
The main goal behind the folksonomic aided searching, from what I understand
(I was not on the team that developed this searching algorithm, I have been
added as someone who can potentially help them get their algorithm into an
existing ILS), is to improve relevance of the results.
I will ta
Chad,
Neat! Always glad to have people volunteer to help make Koha better.
When you say "improve" and "enhance" the search, what are your specific goals?
Faster retrieval time? More complex search options (nested Booleans, more
search fields, regex-style wildcards, etc.)? More relevant rel
Koha uses two methods of searching in the OPAC, and in general. The
first is through third party open source package from IndexData called
Zebra. The second is NoZebra mode. My opinion is that applying your
algorithm to the NoZebra mode would be the easiest option here. Unless
you want to also
I am part of a team of researchers in the Brigham Young University Computer
Science department who are interested in improving the searching used by
Koha's OPAC interface.
Others on the team have come up with a fast and effective way to do
searching using folksonomies and we are interested in addin
Heh. Sounds like a good way to get a headache from information overload ; )
Kyle
http://www.kylehall.info
Information Technology
Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Dec 10, 2009 at 11:42 AM, Walls, Ian wrote:
> If we want to get super-fancy, we could set
If we want to get super-fancy, we could set up a Wave server, and condense the
IRC, mailing lists and blog/wiki/twitter presence into one communications tool.
Then, all the community's knowledgebase would be in one format, distributable
by Git along with the source code, and easily searchable/l
I've always wondered why the developer meetings to place on #koha. It
seems logical to me to have them take place in #developer-meeting or
something similar. The meetings would still be open to all, but people
not interested in the meeting would not interrupt it by accident.
Kyle
http://www.kyleh
Nahuel,
I understand. The intent is to help the developers develop, the users use, and
everyone get more out of Koha. As we get more and more users, and more and
more of them use IRC for questions, it's going to get harder and harder to have
developer-type discussions in the main channel. H
I don't think that the developers should be holding back :) I say
start talking techie in the #koha channel and when people need non
techie talk that can happen to. I use X-Chat and can have 2 channels
open at once, I just don't like the idea of having discussions split
among 2 rooms.
Nicole
On
Le 10/12/2009 16:57, Walls, Ian a écrit :
> I'm reluctant to agree developers should "split off" from users into a
> different channel; it reinforces that perceived divide between users and
> developers that has been used to cast aspersions on the community in the
> past. Having experts in the
I'm with Ian, I think we should all stick together in every way - IRC
channel included.
Nicole
On Thu, Dec 10, 2009 at 10:57 AM, Walls, Ian wrote:
> I'm reluctant to agree developers should "split off" from users into a
> different channel; it reinforces that perceived divide between users and
I'm reluctant to agree developers should "split off" from users into a
different channel; it reinforces that perceived divide between users and
developers that has been used to cast aspersions on the community in the past.
Having experts in the community room is important.
If we could be in tw
Hi all,
I think it should be fine to have a developper irc channel to talk about
technical questions, without been flooded by user/install questions, and
talk only about code guidelines, futur of koha, ways to do, how to do,
etc...
What do you think about this?
bests,
--
Nahuel ANGELINETTI
Yes, the file is xt/perltidyrc, and it represents a compromise consensus
after months of code-format and editor holy wars.
http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=xt/perltidyrc;h=f7d9a3c9be7674a86961f675c46c224d8f72cef0;hb=HEAD
The only other thing that might be useful is a sample
Le 10/12/2009 16:02, Zeno Tajoli a écrit :
> Hi to all,
>
>
>> Deny patches with SQL in .pl scripts, accept "SQL" only in C4, and
>> encourage the use of SQLHelper.
>>
> I don't know what is SQLHelper.
> I do a search on Google and CPAN but I find only a MS tool for C#.
>
> What is it ?
>
Hi to all,
>Deny patches with SQL in .pl scripts, accept "SQL" only in C4, and
>encourage the use of SQLHelper.
I don't know what is SQLHelper.
I do a search on Google and CPAN but I find only a MS tool for C#.
What is it ?
Bye
Zeno Tajoli
CILEA - Segrate (MI)
tajoliAT_SPAM_no_prendiATcilea.it
Didn't someone create a PerlTidy config file for Koha awhile back? I
think that would be an excellent way to easily standardize indentation
rules. If someone has it, it would be nice to have a link to it on the
coding guidelines wiki page.
Kyle
http://www.kylehall.info
Information Technology
Craw
Hi,
Le 10/12/2009 13:56, Paul Poulain a écrit :
> Hello koha-dev,
>
> with koha 3.2 almost knocking on the door, and chris C. ideas for 3.4, I
> think it's time to harden& strengthen our coding guidelines, that are
> really too light. The guidelines are here :
> http://wiki.koha.org/doku.php?id=e
Hello koha-dev,
with koha 3.2 almost knocking on the door, and chris C. ideas for 3.4, I
think it's time to harden & strengthen our coding guidelines, that are
really too light. The guidelines are here :
http://wiki.koha.org/doku.php?id=en:development:codingguidelines
I suggest we create a pag
22 matches
Mail list logo
