Re: [fw-general] Problems with Zend_Search_Lucene
Okay, I changed all paths to absolute path and now it does function but now I
have the problem that all entries breaks before a german Umlaut (äüöß). The
entries are stored in a MySQL database (utf8_unicode_ci).
original: ... Verwaltung, dass ein Paket für mich ...
lucene: ... Verwaltung, dass ein Paket f
I looked into Zend/Search/Lucene/Field.php in line 61 there is iconv() to
convert all utf-8 strings to ansi but I get E_NOTICEs by creating the index.
What can I do to have an index with german Umlauts?
-- Jan
Original-Nachricht
Datum: Fri, 13 Oct 2006 00:13:50 +0200
Von: Jan Pieper [EMAIL PROTECTED]
An: fw-general@lists.zend.com
Betreff: Re: [fw-general] Problems with Zend_Search_Lucene
There is no difference between the dirname with and without the last
slash. Both of them works same.
[EMAIL PROTECTED] cli]# php foo.php
deletable
.
segments
..
_0.cfs
-- Jan
Hi Jan,
Please let me know, what happens if you remove last slash from dirname?
---
$index = new Zend_Search_Lucene('../../lucene/', true);
=
$index = new Zend_Search_Lucene('../../lucene', true);
---
What is the result of:
$dir = opendir('../../lucene/');
while ($file = readdir($dir)) {
echo $file . \n;
}
and
$dir = opendir('../../lucene');
while ($file = readdir($dir)) {
echo $file . \n;
}
???
That also may be something wrong with directory permissions...
With best regards,
Alexander Veremyev.
Jan Pieper wrote:
I am using rev1290 and when I execute this:
?php
/* ... */
echo file_exists('../../lucene/') - .
(file_exists('../../lucene/') ? 'exists' : 'does not exist');
$index = new Zend_Search_Lucene('../../lucene/', true);
/* ... */
?
I´ll get this output:
file_exists('../../lucene/') - exists
Warning: opendir(../../lucene/) [function.opendir]: failed to open
dir: No such file or directory in
/var/www/html/private/lib/Zend/Search/Lucene/Storage/Directory/Filesystem.php
on line 129
Warning: readdir(): supplied argument is not a valid Directory
resource in
/var/www/html/private/lib/Zend/Search/Lucene/Storage/Directory/Filesystem.php
on line 130
The index will be created and I can use it but theses messages
shouldn´t be there.
-- Jan
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: [fw-general] Roadmap question
Hi Bill, first of all thank you very much for your detailed answer. It really delivers a very good insight in the Zend Framework plans for the next month. I think it is a good idea to jump from 0.2 straight to 0.7 to show the improvement of the framework during the last months. Quite a few people I was talking about the framework in the last weeks really thought that the Zend Framework is just reaching 20%. I also think it is a good idea to give each release number a specific name or topic to concentrate on a special goal to reach for this release. Thomas, I guess you will get more support from the community when the I18N Auth release is coming closer. I personally don't mind that you did not set fixed dates for all subsequent releases because nothing is worse than a release date that passes by too long. Thanks again for your comments, the are highly appriciated. Best Regards, Ralf
Re: [fw-general] Roadmap question
Hi Gavin, UNOFFICIAL RESPONSE: If we release ZF 0.2 on Halloween this would be a really nice birthday present ;-) I see that there is a lot of work to be done and it also really is in hands of the community to accelerate the process to head for the ZF 1.0 release. Hopefully I find some time in the near future to pick up some of the issues from the issue tracker to solve them or help solving them. Best Regards, Ralf
[fw-general] Zend_Memory proposal
Hi all, Zend_Memory proposal has been moved to Proposal under review stage. The functionality is distributed between Zend_MemoryManager and Zend_Memory classes and module itself is based on Zend_Cache backends. It's also can be used for sharing data between scripts, but doesn't have this as a primary goal. Welcome for review and feedback! http://framework.zend.com/wiki/x/ZQg With best regards, Alexander Veremyev.
Re: [fw-general] Roadmap question
By all means, I support changing the release number 0.2 (doesn't justify, however late it is to change it) to 0.5 (indicating roughly 50% coverage). Thanks, On 10/12/06, Bill Karwin [EMAIL PROTECTED] wrote: Ralf Eggert wrote: What about the rest of the roadmap? Are there any plans for the further release dates? Okay, I've now updated the rest of the Roadmap in JIRA. We've established a goal to have 0.2.0 ready by the Zend Conference. The Zend Framework is a team effort. Presenting a new release at the Conference would be a great way to show the accomplishments of the ZF community. A huge amount of work has been done since the 0.1.5 release, and we all know that a new, fresh Preview Release is very desirable.Regarding versions following 0.2, we had a talk here at Zend about version numbers. We recognize the terrific work and progress that the community has put into this project, working closely with the staff here at Zend. We feel that continuing with low numbers like 0.2.1, 0.3, etc. doesn't do justice to this progress. It gives the false impression that the 1.0 release is only 20% complete. We don't feel this is accurate. So after 0.2, we'd like to jump to 0.7, and continue from there. Actually, some of us initially thought that we're at 0.7 already, but I want us to have the satisfaction of completing 0.2, which we have all been working toward. Numbers are really just for identifying the phase of the project, and the community has known 0.2 as the name of the current phase for a while, so I didn't want to change that. Since this is an open, community project, I'd like to share with you how I define completion criteria for the releases progressing toward 1.0.Preview release 0.2: The MVC release. As we have been planning, the criteria for 0.2 are the revisions to the MVC architecture. But it's not just MVC; included with this release are all the other enhancements that have been made since 0.1.5. There are also some incubator components that are maturing and may move into core. It is highly desirable for the ZF community and for Zend that this is ready by October 31, so we can announce the release at the Zend Conference. To show such great progress at a public event like that is crucial at this stage of the Zend Framework evolution. Matthew Weier O'Phinney is the project coordinator for the MVC components, but all of us should treat it as a priority to help this effort reach completion. Matthew is going to need help soon with code reviews and testing. Preview release 0.7: The I18N Auth release. Criteria for 0.7 are revisions to the I18N (Locale and others), Zend_Auth, and Zend_ACL architecture and components, as well as enhancements to other components as they are available. Preview release 0.8: The DB release. Criteria for 0.8 are revisions to Zend_DB, as well as enhancements to other components as they are available. Preview release 0.9: Beta. Criteria for 0.9 are that all the remaining components have reached a state of feature complete. This includes the web services components, and a refactored Zend_Filter solution. Components still in incubator at this time will stay in incubator through the 1.0 release. The API's of non-incubator components are relatively stable. Starting at this point, we will refer to the product as Beta instead of Preview Release.Within each of the above releases, we may make a number of point-releases like 0.7.1, 0.7.2, 0.7.3, etc. as justified by the progress. These will be on an irregular, but short timeframe, perhaps about 2 weeks per point-release. This will make the downloadable Preview Release current than it has been. Release 1.0.0: Release Candidate. Criteria for 1.0 are that all non-incubator components are stable, and we've addressed all critical and major issues (not counting feature requests). All components, both core and incubator, have adequate unit tests and reference documentation. The 1.0.0 and subsequent point-releases 1.0.1, 1.0.2, etc. will be referred to as Release Candidates until we are satisfied that Zend Framework is ready for production use. We will strive for perfection during development and during Beta, but we will also have a process for final quality-control criteria. Release 1.0.x: Production. Criteria for 1.0 General Availability (GA) are the same as 1.0.0, as well as satisfying the quality-control standards of Zend, the ZF community, and other users of Zend Framework. I'm reluctant to put dates on these releases. I'd rather let quality and features be the criteria each given release. But if we pitch in to help the main contributors of each component, I'm sure we can make each of these releases an average of four to six weeks apart. Provided that pace continues, it puts the final GA release in March or April of 2007. It's hard to give estimates any more precisely than that. We don't have detailed specs for each component from which to estimate the amount of work. Also, since a lot of the progress is dependent on community
Re: [fw-general] ZF Shirts
Once spreadshirt comes up in a discussion on this mailing list I have to mention my own shirt company where I use the same technique as spreadshirt does... only difference: I sell them cheaper ;) I hope you understand that I just couldn't resist this bit of advertisement right now... too tempting. Website only in German right now: http://shirts.gleichjetzt.de Cheers, Axel Alexander Kops wrote: It might be http://www.spreadshirt.com you were looking for ;) cya, Alex Stefan Koopmanschap schrieb: Cafepress doesn't do quality shirts though. There is a german company that does much better quality shirts. I forgot the name right now but could dig it up. I have an account there and could easily get a design up and running there and sell it against the lowest price possible. I think they're slightly more expensive than cafepress, but for that price you get an actual good quality print. they require a vector design btw ;) On 10/12/06, *Chris Hartjes* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 10/12/06, Richard Thomas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://benramsey.com/archives/phpc-t-shirts/ Someone should do the same for us ;) CafePress would let you set something up like that pretty quickly... -- Chris Hartjes The greatest inefficiencies come from solving problems you will never have. -- Rasmus Lerdorf @TheBallpark - http://www.littlehart.net/attheballpark @TheKeyboard - http://www.littlehart.net/atthekeyboard http://www.littlehart.net/atthekeyboard -- Stefan Koopmanschap http://www.stefankoopmanschap.nl/ http://www.leftontheweb.com/ http://www.leftontheweb.com/
Re: [fw-general] ZF Shirts
Sponsorship? ;) - Original Message - From: Axel Christ [EMAIL PROTECTED] To: Zend Framework General fw-general@lists.zend.com Sent: Friday, October 13, 2006 5:06 PM Subject: Re: [fw-general] ZF Shirts Once spreadshirt comes up in a discussion on this mailing list I have to mention my own shirt company where I use the same technique as spreadshirt does... only difference: I sell them cheaper ;) I hope you understand that I just couldn't resist this bit of advertisement right now... too tempting. Website only in German right now: http://shirts.gleichjetzt.de Cheers, Axel Alexander Kops wrote: It might be http://www.spreadshirt.com you were looking for ;) cya, Alex Stefan Koopmanschap schrieb: Cafepress doesn't do quality shirts though. There is a german company that does much better quality shirts. I forgot the name right now but could dig it up. I have an account there and could easily get a design up and running there and sell it against the lowest price possible. I think they're slightly more expensive than cafepress, but for that price you get an actual good quality print. they require a vector design btw ;) On 10/12/06, *Chris Hartjes* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 10/12/06, Richard Thomas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://benramsey.com/archives/phpc-t-shirts/ Someone should do the same for us ;) CafePress would let you set something up like that pretty quickly... -- Chris Hartjes The greatest inefficiencies come from solving problems you will never have. -- Rasmus Lerdorf @TheBallpark - http://www.littlehart.net/attheballpark @TheKeyboard - http://www.littlehart.net/atthekeyboard http://www.littlehart.net/atthekeyboard -- Stefan Koopmanschap http://www.stefankoopmanschap.nl/ http://www.leftontheweb.com/ http://www.leftontheweb.com/ __ NOD32 1.1380 (20060125) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Re: [fw-general] Roadmap question
By all means, I support changing the release number 0.2 (doesn't justify, however late it is to change it) to 0.5 (indicating roughly 50% coverage). I think we would all support changing 0.2 to 0.5, especially in light of the upcoming Zend conference. -Matt
Re: [fw-general] Wiki - Docbook
Andries,
Regarding semantics, information lost when converting *our* docbook to
wiki could be saved by embedding trivial wiki comments. As a
practical matter, almost everything found in our docbook files have
corresponding equivalents in Confluence and can be translated back and
forth between docbook and wiki. Regarding the comment from Atlassian,
they were referring to the complexity of trying to convert Confluence
macros to docbook, since Confluence supports user-supplied macros that
are basically Java plugins producing HTML. The handful of macros we do
use in the wiki seem to map nicely to docbook equivalents (e.g.
{code:xml} for programlisting role=xml).
We all know wiki markup is not equivalent to docbook, but instead of
worrying out trying to make perfect conversions back and forth, I
suggest we focus on looking at a specific blocks of code (a real ZF .xml
docbook file, and the corresponding wiki file), to avoid getting lost
and overly concerned about abstract, hypothetical situations or problems
that might not be relevant to our data.
If the community wants to have the ease, simplicity, and pleasure of
using our wiki and commenting features, instead of continuing our
current editing of XML docbook files, then I'm sure we can resolve any
concerns regarding converting back and forth between docbook and the
wiki formats. Also, for our current use of the docbook, the aptconvert
and similar tools raise the question of whether or not we really need
docbook at all.
Cheers,
Gavin
Andries Seutens wrote:
Hello all,
I have been doing some research on doing the wiki to docbook
conversion, however I think it is tricky because you would have to
infer a lot of semantics to get Docbook out of wiki markup.
Wiki-markup is decidedly presentational, which means that we can
transform it quite effectively into other presentational markups (PDF,
non-strict HTML), but not so effectively into semantic markup.
There is a comment somewhere else by an Atlassian employee saying that
a docbook export functionality would require each macro to support
docbook. Therefore docbook would never be supported. I think this is a
valid point, although i don't like that either.
I have found one other alternative that might by valuable to us: APT.
http://www.xmlmind.com/aptconvert.html
We could export our wiki markup (it already looks a lot like APT) and
then use APTConvert to transform it into HTML, XHTML, PDF, PostScript,
(MS Word loadable) RTF, DocBook SGML and DocBook XML
What are your thoughts on this manner?
Best regards,
Andries Seutens
Belgium
http://andries.systray.be
