[PHP-DEV] Enchant
Hi. Has this extension been changed to use differently named external libraries. Previously in V5.3.2-dev, php_enchant.dll was working with ... libglib-2.0.0-0.dll libgmodule-2.0-0.dll I've had to copy these to glib-2.dll gmodule-2.dll to get enchant to work again. What is odd, in looking through my dependency viewer... C:\PHP5\ext\PHP_ENCHANT.DLL requires C:\PHP5\PHP5.DLL and C:\PHP5\LIBENCHANT.DLL Nothing wrong so far. C:\PHP5\LIBENCHANT.DLL requires C:\PHP5\GLIB-2.DLL and C:\PHP5\GMODULE-2.DLL This is where the change has happened. BUT... C:\PHP5\GMODULE-2.DLL requires C:\PHP5\LIBGLIB-2.0-0.DLL So I've now got 2 identical versions of LIBGLIB-2.0-0.DLL loaded (via different names). As I'm on windows, I can't have a unix style link for the name. Renaming C:\PHP5\LIBGLIB-2.0-0.DLL to C:\PHP5\LIBGLIB-2.0-0.DLLORG generates the usual error regarding missing libraries. See http://pearl.slingfile.com/dl/78ce6dbf23973ba2c40a794a3e30f8b5/4ad6e20c/hd1/sf/uploads/image/223787/LibEnchant%20Issue.png for screenshot -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 13.10.2009, at 10:34, Samuel ROZE wrote: http://wiki.php.net/rfc/pdonotices I assume that calling noticeInfo() will also purge all currently stored notices (maybe controllable via some parameter)? For MySQL we would have to throw an error/exception in case there is a result set open on the same connection. I still believe that it makes sense to add this functionality. Without it we would have to add database specific solutions for various drivers. PostgreSQL being the obvious one, but even for MySQL it would make sense to then at least expose the warning count etc. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enchant
hi, Please repost to the windows internals list. That's a win packaging issue. Cheers, On Thu, Oct 15, 2009 at 10:50 AM, Richard Quadling wrote: > Hi. > > Has this extension been changed to use differently named external libraries. > > Previously in V5.3.2-dev, php_enchant.dll was working with ... > > libglib-2.0.0-0.dll > libgmodule-2.0-0.dll > > I've had to copy these to > > glib-2.dll > gmodule-2.dll > > to get enchant to work again. > > What is odd, in looking through my dependency viewer... > > C:\PHP5\ext\PHP_ENCHANT.DLL requires C:\PHP5\PHP5.DLL and > C:\PHP5\LIBENCHANT.DLL > > Nothing wrong so far. > > C:\PHP5\LIBENCHANT.DLL requires C:\PHP5\GLIB-2.DLL and C:\PHP5\GMODULE-2.DLL > > This is where the change has happened. > > BUT... > > C:\PHP5\GMODULE-2.DLL requires C:\PHP5\LIBGLIB-2.0-0.DLL > > So I've now got 2 identical versions of LIBGLIB-2.0-0.DLL loaded (via > different names). > > As I'm on windows, I can't have a unix style link for the name. > > > Renaming C:\PHP5\LIBGLIB-2.0-0.DLL to C:\PHP5\LIBGLIB-2.0-0.DLLORG > generates the usual error regarding missing libraries. > > See > http://pearl.slingfile.com/dl/78ce6dbf23973ba2c40a794a3e30f8b5/4ad6e20c/hd1/sf/uploads/image/223787/LibEnchant%20Issue.png > for screenshot > > > > > > > > -- > - > Richard Quadling > "Standing on the shoulders of some very clever giants!" > EE : http://www.experts-exchange.com/M_248814.html > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > ZOPA : http://uk.zopa.com/member/RQuadling > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On Wed Oct 14 04:07 PM, Lukas Kahwe Smith wrote:
>
> On 14.10.2009, at 22:03, Stanislav Malyshev wrote:
>
> > Hi!
> >
> >>> So lets warm this up again.
> >>> HEAD is for development .. so lets get this into HEAD so that it
> >>> will be part of the next bigger PHP release for sure!
> >> Well, the code is sitting here
> >> http://github.com/gron/php-src/tree/PHP_6-traits
> >> and waits to be merged. :)
> >
> > I thought before merging code it would be useful to have some
> > discussion on if the code is actually doing what we want. If it's
> > based on http://wiki.php.net/rfc/horizontalreuse then for example I
> > can see some potential issues for bytecode caching related to
> renaming
> > and changing visibility.
> > Also, it is not clear that we want grafts there at all, some aspects
> > of them seem to get too hairy, esp. $this issue or statics.
> >
>
> i think Stefan is fully aware of that probably there will be a
> discussion first ..
> but i think we all agree that this feature is very high on the list of
> what people want and therefore i wanted to get this discussion going,
> so that after its concluded traits can be commited to HEAD.
Has it been discussed to add a portion of the patch to HEAD?
Reading up on scala, I really like what they've done with traits (as a
developer):
http://www.scala-lang.org/node/117
I've updated the RFC with an example:
http://wiki.php.net/rfc/traits#scala_synthax_and_practical_example
Hopefully, people can agree on a simple patch that ignores conflict
resolution / aliasing solution and just adds:
trait User_Comments {}
class App_Document with User_Comments {}
// Or the original syntax
class App_Email {
use User_Comments;
}
The details of conflict resolution, if the use cases are strong enough can
come later.
Grafts well... the re-use is interesting but I worry about how php is going
to evolve is you start offering that much flexibility.
Just my thoughts, great work though.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Sure, the discussion will be necessary to fix the final design of the remaining rough edges like choice of keywords. The current state of the code is basically documented by the test case. They cover all syntactical features and their implications for using traits. However, this functionality is covered by the Traits part of the RFC as well. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. Personally, I see question of Traits or Grafts as an exclusive one. It would not do any good to have both of them. And, grafts have not been implemented. Best regards Stefan -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Hi: On 14 Oct 2009, at 22:44, Tom Boutell wrote: I'm very concerned about the practical consequences of introducing traits without state. Well, we have not found a sufficient design until now, which would fit nicely into PHP from dynamic and simplicity perspective. A. They could do this using static hashes in global variables or a separate class. The result is a garbage collection failure as these references to $this will never go away. Designed-in GC failures are unacceptable post PHP 5.3. Doing this would be less than advisable. B. PHP allows you to define properties at runtime. That is, you can write: $this->title = 'my title'; Without declaring var $title; at the class level. But PHP 6 seems to be moving toward more strictness, not less, and this style encourages the use of undeclared variables with the resulting potential for missed bugs. Thats the currently preferred approach from my perspective. The only thing you are going to lose here is a notion of separation of state from different traits, compared to a language supported approach. However, if you prefer to be more strict, it is still perfectly possible to circumvent this problem by using getters and setters. Also, the 'instead' keyword is baffling - it could mean replace A with B or replace B with A depending on how you place your mental comma - I much prefer the assignment syntax alternative, or 'insteadof' which is unambiguous. Yes, that was discussed before, but unfortunately did not make it into the list of alternative syntaxes, will try to keep track of it. Best regards Stefan On Wed, Oct 14, 2009 at 4:07 PM, Lukas Kahwe Smith wrote: On 14.10.2009, at 22:03, Stanislav Malyshev wrote: Hi! So lets warm this up again. HEAD is for development .. so lets get this into HEAD so that it will be part of the next bigger PHP release for sure! Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits and waits to be merged. :) I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. i think Stefan is fully aware of that probably there will be a discussion first .. but i think we all agree that this feature is very high on the list of what people want and therefore i wanted to get this discussion going, so that after its concluded traits can be commited to HEAD. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On Thu, Oct 15, 2009 at 10:42 AM, Stefan Marr wrote: > Hi: > > On 14 Oct 2009, at 22:44, Tom Boutell wrote: > >> I'm very concerned about the practical consequences of introducing >> traits without state. > > Well, we have not found a sufficient design until now, which would fit > nicely into PHP from dynamic and simplicity perspective. Could you elaborate a little? I'm having trouble understanding why we can't just implement trait properties according to exactly the same policy we're using for methods with regard to conflict resolution/renaming and all the rest of it. >> B. PHP allows you to define properties at runtime. That is, you can write: >> >> $this->title = 'my title'; >> >> Without declaring var $title; at the class level. > > Thats the currently preferred approach from my perspective. > The only thing you are going to lose here is a notion of separation of state > from different traits, compared to a language supported approach. > > However, if you prefer to be more strict, it is still perfectly possible to > circumvent this problem by using getters and setters. So the trait would continue to use this tactic (runtime assignment to previously undeclared properties) internally, and wrap that in getters and setters... Will PHP ever include optional warnings for the use of undeclared properties? If so, then it doesn't make sense to also institutionalize their use as the only right way to have state in traits. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
Hi:
Has it been discussed to add a portion of the patch to HEAD?
Hopefully, people can agree on a simple patch that ignores conflict
resolution / aliasing solution and just adds:
Ehm, hopefully not...?
The power of traits is the explicit resolution of conflicts.
And at least for me, that is the interesting part here.
I agree that mixins (traits without explicit conflict resolution) are
easier to begin with, but they have problem in the long run.
Linearization introduces brittle architectures, which does not cope
well with changes.
Tom mentioned that he thinks that PHP6 is moving in a more strict
direction, probably that is also motivated by the large systems
already out there, for which people tend to prefer more strict
language features.
In this sense, an explicit conflict resolution is a must-have.
Anyway, could I ask you to move your changes from the outdated RFC
over to the one we are talking about? (http://wiki.php.net/rfc/horizontalreuse
)
Best
Stefan
PS: Is there a way to have a watermark or something which marks the
old RFC as outdated? I don't want to delete it for documentation
purpose...
trait User_Comments {}
class App_Document with User_Comments {}
// Or the original syntax
class App_Email {
use User_Comments;
}
The details of conflict resolution, if the use cases are strong
enough can
come later.
Grafts well... the re-use is interesting but I worry about how php
is going
to evolve is you start offering that much flexibility.
Just my thoughts, great work though.
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax: +32 2 629 3525
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit : > On 13.10.2009, at 10:34, Samuel ROZE wrote: > > > http://wiki.php.net/rfc/pdonotices > > > I assume that calling noticeInfo() will also purge all currently > stored notices (maybe controllable via some parameter)? If purge all notices, without parameter, like errorInfo. > For MySQL we would have to throw an error/exception in case there is a > result set open on the same connection. Is it really impossible to query Database if there is another result set opened ? If there's a result set opened seems that there's another query in the same time with the same code ? Is it possible ? I don't think so... > I still believe that it makes sense to add this functionality. > Without it we would have to add database specific solutions for > various drivers. PostgreSQL being the obvious one, but even for MySQL > it would make sense to then at least expose the warning count etc. I still believe into it too ! I'll work about if I've more replies about the RFC. I have got any other replies... Samuel. > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 15.10.2009, at 19:40, Samuel ROZE wrote: Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit : On 13.10.2009, at 10:34, Samuel ROZE wrote: http://wiki.php.net/rfc/pdonotices I assume that calling noticeInfo() will also purge all currently stored notices (maybe controllable via some parameter)? If purge all notices, without parameter, like errorInfo. For MySQL we would have to throw an error/exception in case there is a result set open on the same connection. Is it really impossible to query Database if there is another result set opened ? If there's a result set opened seems that there's another query in the same time with the same code ? Is it possible ? I don't think so... yeah .. thats just how it is in MySQL. the warnings are stored in the connection so even opening a second connection to be able to execute another query isnt going to help at all. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
