Re: [Musicpd-dev-team] [pull request] fix buffer and segfault in encoder/shine
On 2014/01/13 21:52, Andrée Ekroth andree.ekr...@gmail.com wrote: Hello, - I have removed the unnecessary buffer we talked about in the IRC. Merged. - I also found a bug in the shine library which I added a workaround for. Basically the encoder can't initialize until MPD calls write the first time, or else it results in a segmentation fault. Hm, I don't like how you did this. This bug is unfortunate, but your workaround complicates the code. Another idea: if nothing was written, the close method shall write zeroes. The advantage is that the workaround lives only inside the close method, and there's no initialization postponed to the write method. Note that this commit introduces a compiler warning because the error parameter is now unused. I always configure with --enable-werror, please do the same. When you find a typo in your commit, don't write a new commit - amend the existing one. (Given that the wrong commit was not yet merged.) -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] AlsaInputPlugin
On 2014/01/08 14:10, Steven OBrien steven_obri...@yahoo.co.uk wrote: The high CPU load in the Alsa input plugin was caused by a mistake in the alsa software parameters configuration. Clearly I misunderstood what this particular setting was for. The attached patch simply removes the setting of that parameter and now the plugin runs very smoothly for me with ~0.3% CPU load. Merged. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] user documentation for alsa input plugin
On 2014/01/08 22:48, Steven OBrien steven_obri...@yahoo.co.uk wrote: The attached patch adds a simple section to doc/user.xml for the Alsa input plugin Steven Merged. btw. you don't need to write text in your email. Just the patch is enough. If you want to continue contributing to MPD, consider getting a public git repository, for example here: http://git.musicpd.org/account-policy.html -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] AlsaInputPlugin
On 2014/01/07 13:59, Steven OBrien steven_obri...@yahoo.co.uk wrote: Since my last update, I've been thinking that the alsa poll is really just a timer, it fires every time a fixed number of frames have been written to its internal buffer, and as a real-time stream this equates to a fixed number of milli-seconds. So the MPD code would be much simpler if we could just use a TimeoutMonitor to produce the wake-up instead of trying to integrate with the alsa lib here. No, bad idea, because you never know when exactly the data will be available. What if you wake up too early? Or too late? The only way to do it properly is let the audio device do the timing, and follow that. The audio device is the authority here. Guessing when it will deliver is error prone. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] GIT: Account request - DarkFox
On 2014/01/04 14:20, James McGlashan d...@darkfox.id.au wrote: Realname: James McGlashan Email: m...@darkfox.id.au Username: darkfox Projects: MPD, maybe ncmpc SSH-Key FP: ee:fa:8c:17:0a:16:03:ed:17:ad:53:77:df:a7:73:54 http://git.musicpd.org/cgit/darkfox/mpd.git/ http://git.musicpd.org/cgit/darkfox/ncmpc.git/ -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/12/02 11:12, Denis Krjuchkov de...@crazydev.net wrote: I've added poll based PollGroup implementation: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=1df426aa5c571d3d88ecb7bed6b8ed9b32c15e32 After quick testing connecting with client and playing http streams work, however I didn't succeed in using http output. I have now fixed the remaining problems (which were not in your code, but in my httpd plugin code), and it appears to work now. I have just removed our GLib implementation of EventLoop. There's no use for it anymore. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] S24_3BE
On 2013/12/19 19:21, hiro 23h...@gmail.com wrote: mpd (MPD: Music Player Daemon) 0.16.7 We can stop here. This version is so old, I don't support it. Even for the 0.16 branch, this is not the newest bugfix release. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UPnP db plugin
On 2013/12/18 10:02, j...@dockes.org wrote: +static const string rootid(0); Using std::string here is useless bloat, isn't it? There's much more of this useless bloat in your code. I do not think that this is useless bloat, except if you consider that std::string is useless bloat in general. As most of the code is based on std::string, defining the constant as such means that we do not incur a char*-to-std::string conversion each time the constant is used (to construct another string). When would this conversion happen? Use nullptr instead of 0. 0 is obscure. 0 is not obscure, as it was the standard up to really recently (NULL usage was discouraged by Stroustrup himself, you can easily google for this). It WAS the standard. MPD was not designed for this outdated standard. It was rewritten to C++11. When MPD was C99, it used NULL - Stroustrup's opinion does not matter here, because he was talking about C++. Now MPD uses C++11, and it shall use nullptr - Stroustrup's opinion still does not matter, because it's obsolete. I am all for converting to nullptr, but saying that 0 is obscure is a bit of an exaggeration. It obscures the nature of the variable. Using 0 implies that it's an integer, but it's not. It was obscure even when it was the standard. This old standard is obsolete for a good reason. I can change the declaration order if you really insist, but you should be aware that many people (e.g. Google standards) quite logically recommend to put the public declarations (the interface) first, and the private stuff (including the data members) last because this improves readability. There are arguments both for both sides. It boilds down to personal opinion. There are no logical super-arguments for any. I criticized your coding style because it does not follow what the rest of MPD does. Google standards are irrelevant here. The variables are not passed as std::string but as const refs to std::string, so, no overhead. Const or not const does not matter for the question of whether it's overhead, does it? It is overhead because a simple string literal must be converted to std::string each time the function is called - and that implies a heap allocation and deallocation. I actually don't understand your remark. Using std::string for everything except when constrained by an external interface is just good c++ practise. Maybe in your opinion. It's not in my opinion. MPD uses C++ syntax because it is easier to write than C. I converted MPD from C99 to C++ when C++11 came, which allowed me to eliminate most of the runtime overhead. Only then was C++ acceptable for me. Now you're adding all the C++ bloat that I feared, why I have been disliking C++ for so many years. Using a writable ref for returning the result avoids copying a possibly expensive object. This is also just good practise and I think that it's not clear to you because you are not used to it: non-const refs are for returning data, else they would be const... You may want to read https://en.wikipedia.org/wiki/Return_value_optimization What is reallyOpen()? The method name is obscure. I have to delay initialization of libupnp until after mpd daemonizes, else the lib does not work. I don't know if the fork does it or some descriptor manipulation. So it's a kludge to work around a MPD initialization order problem. This should be well-documented in a code comment so it can be eliminated once the MPD core has been improved. And you should write a ticket to request this improvement. + if (m_root) + return true; What does that check mean? As reallyOpen() has to be called for every visit call this is checking if we need to actually do something or we're already done. Setting m_root is the last thing the method does when really working. I could put the test at the call locations, but I find it cleaner this way. Again, there should be a code comment explaining this kludge. + FormatDebug(db_domain, UpnpDatabase::reallyOpen\n); Do we need those debug messages? What value do they add? Well, they're used for debugging actually. I could remove them, but having traces for the main function calls is really useful. I can ifdef all this away if you prefer. No. Please remove them completely. I'm not convinced that they are really useful. They just clutter the log file. + // Wait for device answers. This should be consistent with the value set + // in the lib (currently 2) + sleep(2); No, no, no. I had a hard time removing all those sleep() calls from MPD, and I'm not even finished - I will not allow adding new ones. This is extremely bad style. Completely not acceptable. Blocking is bad enough, but waiting for a compile-time constant amount of time for some event to happen, without knowing how long it will really take - no! When the UPnP discoverer inside the
Re: [Musicpd-dev-team] UPnP db plugin
On 2013/12/18 14:43, j...@dockes.org wrote: Please delete my repository from the musicpd site, Done. I've also deleted your Mantis account, and I'll disable your mailing list subscription. Please do not bother me again after calling me a liar. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] S24_3BE
On 2013/12/18 22:21, hiro 23h...@gmail.com wrote: I had been using mpd with a S24_3LE soundcard in the past, now I setup another system and I would need to use S24_3BE, not LE. But whatever settings I make I only get static unless I make alsa do the conversion job (plughw) Is this unsupported, undocumented or a bug (in the source I find BE mentioned, but in the same function that is also used for LE, not sure if the difference is ignored or not). It should just work, but I'm unable to test because I don't have any S24_3 capable hardware. When you play back 24 bit audio, and ALSA refuses to configure padded 24 bit, MPD will try to use the packed format (S24_3). First, it will try host byte order, and then reverse byte order. Write a bug report, and paste all relevant data (config, mpd --version, verbose log, /proc/asound/... etc.) -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UPnP db plugin
On 2013/12/17 18:08, j...@dockes.org wrote:
Max Kellermann writes:
I see many bug fix commit, which fix bugs introduced earlier by
yourself. This is confusing to read, and makes the repository hard to
bisect. Please fold those into the commit that introduced the bug.
Ok, then, I've squashed everything into one commit, as the history was
all bug fixes over the initial code add.
Please fix indentation. You mix tabs and spaces, and obviously your
tab width is not 8. Also, please remove all whitespace at the end of
code lines.
Use pkg-config instead of AC_CHECK_LIB. That's more reliable and
easier to use.
+static const string rootid(0);
Using std::string here is useless bloat, isn't it? There's much more
of this useless bloat in your code.
Use nullptr instead of 0. 0 is obscure.
Don't use m_ prefixes for variable names. Put class variables on
top, not at the bottom, just like the rest of the C++ code does.
+static void stringToTokens(const string str, vectorstring tokens,
+ const string delims = /, bool skipinit = true)
This should return the vector instead of passing a writable reference.
Using reference parameters for return values is obscure. And I think
this function should live in src/util/.
Passing delims and str as std::string is useless bloat, again.
What is reallyOpen()? The method name is obscure.
+ if (m_root)
+ return true;
What does that check mean?
+ FormatDebug(db_domain, UpnpDatabase::reallyOpen\n);
Do we need those debug messages? What value do they add?
+ // Wait for device answers. This should be consistent with the value set
+ // in the lib (currently 2)
+ sleep(2);
No, no, no. I had a hard time removing all those sleep() calls from
MPD, and I'm not even finished - I will not allow adding new ones.
This is extremely bad style. Completely not acceptable. Blocking is
bad enough, but waiting for a compile-time constant amount of time for
some event to happen, without knowing how long it will really take -
no!
+ // TBD decide what we do with the lib and superdir objects
What does that mean?
+// Transform titles to turn '/' into '_' to make them acceptable path
+// elements. There is a very slight risk of collision in doing
+// this. Twonky returns directory names (titles) like 'Artist/Album':
Please use doxygen-style comments for API documentation. Some more
API documentation would be nice.
+static mapstring, TagType propToTag = {
+static mapunsigned int, string tagToProp = {
Bloat! Use tag_table instead.
+ std::ostringstream oss;
+ oss Unknown tag value tagnum;
+ return oss.str();
That code should not be reachable. Ensure that and convert to
assert(). But, anyway:
+// Debug/printing: translate MPD tag value to string
+// Debug/printing: print out a SongFilter
Do we really need that?
+/* Local Variables: */
+/* mode: c++ */
+/* c-basic-offset: 4 */
+/* tab-width: 4 */
+/* indent-tabs-mode: t */
+/* End: */
Here it is: tab-width 4. Please remove this section and correct your
editor configuration!
+ * ExpatMM - C++ Wrapper for Expat available at http://expat.sourceforge.net/
Please not another code duplication.
Is this C++ wrapper really worth it? I use plain expat, even in C++.
Wrapping expat in a C++ interface just adds bloat with no advantage.
+class PTMutexInit {
MPD already has a Mutex class, one that is portable. Why do we need a
new one, one that is not portable?
+extern std::string path_getfather(const std::string s);
MPD already has code for dealing with path names. No more code
duplication!
+#define PLOGINF(...) UpnpPrintf(UPNP_INFO, API, __FILE__, __LINE__,
__VA_ARGS__)
+#define PLOGDEB(...) UpnpPrintf(UPNP_INFO,API, __FILE__, __LINE__, __VA_ARGS__)
Another logging library? MPD already has one.
+#include sstream
Referencing iostream in MPD adds a huge amount of bloat (even without
actually using it). We don't use it currently, and I don't see any
sensible use of it in your commit. Please remove.
+LibUPnP(const LibUPnP ) {}
+LibUPnP operator=(const LibUPnP ) {return *this;};
W T F. An assignment operator/constructor that does nothing. That is
insane code!
+#include tr1/unordered_map
+#include tr1/unordered_set
Don't use TR1 headers. We have C++11, and that's part of the standard
now.
+if ((err = pthread_create(thr, 0, workproc, arg))) {
That code is not portable. Please use MPD's portable threading
library.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
[Musicpd-dev-team] --disable-glib
There is now a configure option called --disable-glib. No, unfortunately it doesn't work yet, but I'll use it to track TODOs on our way to eliminate GLib. The following 23 files still reference GLib (only listing those that cannot be disabled by other compile-time options): src/Page.cxx src/Directory.cxx src/ExcludeList.hxx src/ExcludeList.hxx src/Timer.cxx src/PlaylistFile.cxx src/PlaylistSave.cxx src/UpdateContainer.cxx src/Song.cxx src/cue/CueParser.cxx src/SongSort.cxx src/SongFilter.cxx src/DecoderBuffer.cxx src/tag/TagString.cxx src/tag/TagBuilder.cxx src/tag/TagPool.cxx src/tag/TagConfig.cxx src/fs/Config.cxx src/util/fifo_buffer.c src/event/ServerSocket.cxx src/fs/Charset.cxx src/fs/TextFile.cxx src/fs/AllocatedPath.cxx -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FS improvements + refinements in PollGroupWinSelect
On 2013/12/05 17:10, Ben Boeckel maths...@gmail.com wrote: On Thu, Dec 05, 2013 at 19:17:56 +0600, Denis Krjuchkov wrote: g_get_home_dir() works differently depending on GLib version. Newer GLib versions check $HOME first and if it's empty use getpwnam_r() to obtain home directory for currently user. Old versions go straight into using getpwnam_r(). What approach should we use? Please use $HOME then fall back to getpwnam_r(). Agree. $HOME is the nearest variable, one that can be customized easily by users. One can not override /etc/passwd entries easily. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FS improvements + refinements in PollGroupWinSelect
On 2013/12/04 09:51, Denis Krjuchkov de...@crazydev.net wrote:
I'm going to replace remaing GLib path management functions.
However I have some thoughts at first:
I think PathTraits type could be split into two types.
One for native paths and one for UTF-8 paths.
They could have similar symbol names (e.g. Build, IsAbsolute).
This would allow writing more general path management algorithms using
templates with specific traits template parameter.
On contrary there would be only few functions so copy-and-paste solution
might no so bad (easier to read, faster compile, etc).
Merging duplicate code is good, even if it's just about a few lines.
Compile times don't matter a lot. I chose C++ even though C++ is a
lot slower than C (at compile time, not at runtime).
We need to be careful when to merge code, because sometimes, there are
differences; for example, UTF-8 strings shall always use slash and
never backslash. That is not currently documented or enforced, but
may be a good idea to implement for better Windows compatibility.
UTF-8 paths shall be portable paths, while FS paths may have OS
specifics.
This function looks suspicious for me:
std::string
PathTraits::GetParentUTF8(const char *p)
{
assert(p != nullptr);
const char *slash = strrchr(p, SEPARATOR_UTF8);
return slash != nullptr
? std::string(p, slash)
: std::string(.);
}
If given rooted path (for example '/foo') it would return empty string
which is not valid path. This might be OK for MPD virtual UTF-8 paths,
however it's definitely not OK for real paths because empty string is
never a valid directory. This leaves me in twofold situation.
If I implement GetParentFS() to return '/' if given rooted path it would
be inconsistent with GetParentUTF8(). If I change GetParentUTF8() to
return '/' if given rooted path I'm not sure if this won't break
anything in database operation and other places.
The root directory is some sort of special case that was not
considered here, you're right. It is special because it ends with a
slash, while normal directory names should not. Care must be taken
to avoid double slashes.
One more suspicious thing is PathToUTF8() function:
On Windows we accept both '/' and '\' as path separators.
However UTF-8 paths always use '/'. This means if path that contains
backslashes is converted to UTF-8 it can not be safely returned to
client because it would treated incorrectly (I assume MPD protocol does
not have special meaning of backslash). From what I saw in the code this
functions is mostly used in logging, which is safe. But I'm not sure if
there are no hidden bugs in this logic.
The backslash is the escape character for arguments in the MPD
protocol.
A client should never see a backslash as a path separator. So yes, it
should be converted (see above).
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FS improvements + refinements in PollGroupWinSelect
On 2013/12/03 09:58, Denis Krjuchkov de...@crazydev.net wrote: I think you're right. Pushed a fix for that. Merged. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/12/02 11:12, Denis Krjuchkov de...@crazydev.net wrote: I've added poll based PollGroup implementation: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=1df426aa5c571d3d88ecb7bed6b8ed9b32c15e32 After quick testing connecting with client and playing http streams work, however I didn't succeed in using http output. I think it still could be merged because it's not completely useless and this backend is not activated by default anyway. Agree. We'll figure out the remaining bugs. Merged. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/29 10:40, Denis Krjuchkov de...@crazydev.net wrote: I've added Windows select backend for event loop as well as few fixes. Merged. I like how well the incremental way of doing this works. When you've added the portable poll() implementation, we'll test it, and then we will eventually remove the GLib code. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/29 19:18, Denis Krjuchkov de...@crazydev.net wrote: I'm wondering is there any plan for GLib removal in particular and tasks for new version in general? No, there is no grand plan. Things just happen whenever somebody chooses to spend time on the code ;-) There are quite a few ideas I have, and most of the time, I prepare for them by refactoring code. For example, the GLib removal will lead to the Android port. Multi-player support is one rather large feature (multiple players inside one MPD process), and during 0.18 development, there were many preparations for this (struct Partition), but this will take a long time. I think it would be very convenient to have such list so we can split tasks, discuss implementation details, etc. http://bugs.musicpd.org looks like a suitable place for such things, but as far as understand currently it's used for user feedback and user feature requests. What do you think? Yes, why not. Tell me your Mantis user name, and I'll raise your privileges. Then you can manage all the tickets you'd like to do. Max -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/28 16:30, Denis Krjuchkov de...@crazydev.net wrote: I've added one more patch. This introduces generic poll API as well as implementation for epoll. Merged. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/27 14:18, Denis Krjuchkov de...@crazydev.net wrote: OK. Do you have any comments on the patch itself? Just read it merged. Looks excellent! -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH 1/1] fix typo in man page
On 2013/11/26 10:22, Christian Hesse m...@eworm.de wrote: --- doc/mpc.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Merged -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Few more fixes
On 2013/11/26 13:18, Denis Krjuchkov de...@crazydev.net wrote: HttpdOutputPlugin.cxx: fix null pointer dereference Main.cxx: initialize winsock before creating IO thread configure.ac: set VERSION_MINOR to 19 Merged -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New command line parser
On 2013/11/24 12:34, Denis Krjuchkov de...@crazydev.net wrote: this time I'm reworking command line parsing to avoid using g_option stuff. I was wondering whether we should use boost for that. Now you implemented a new parser. Why that? -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New command line parser
On 2013/11/24 14:08, Denis Krjuchkov de...@crazydev.net wrote: 24.11.2013 18:38, Max Kellermann ??: I was wondering whether we should use boost for that. Now you implemented a new parser. Why that? Why not? Probably for the complex cases it's better to use a library* but MPD currently uses very simple flag options that are easily parsed without any library. If you intention was to add many other command line options in the future this probably is not the way to go. On the other side if the goal is to remove GLib this looks fairly suitable. Sound fair. I've merged it, thanks. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/19 13:12, Denis Krjuchkov de...@crazydev.net wrote: I'm trying to implement new event loop for MPD without GLib (or any other library). It's borrowed from existing epoll-based event loop. I only abstracted API differences behind general inteface (PollGroup class). Currently there are 3 backends: poll(), epoll() and Windows variant of select(). Code is poorly tested and has no comments at the moment, consider this a prototype. My few cents: - you reordered code in event/Loop.cxx, which makes reading the diff more difficult than necessary - the PollGroup/PollGroupImpl indirection adds unnecessary runtime overhead, without any advantage - why did you remove class EPollFD? Instead, PollGroupEPoll contains this abstraction code, plus the PollGroupImpl code. - why add overhead by storing the events in EventQueue? My implementation could work without this storage class. Your commit adds this overhead even to the epoll implementation. - why implement the SocketSet copy constructor? - you removed all the GLib code in that one commit, and added all new (untested) implementations; much of the commit deals with removing GLib specific code The last one is unfortunate, because it means we have to do the full switch in one big step. It would be better to have incremental patches which add one (optional) new implementation at a time; now we have to be sure all of them are mature at the same time. At the end, when we are portable across all platforms, we could remove the GLib implementation. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using MPD to play music from an UPnP Media Server
On 2013/11/02 16:11, j...@dockes.org wrote: Hi, I have uploaded the code for a UPnP Database plugin to git://git.musicpd.org/medoc/mpd.git One more thing, I had a very quick look at the first commit that adds code: you added a copy of libexpat. Why that? Why not link this library, like everybody else does? -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using MPD to play music from an UPnP Media Server
On 2013/11/04 19:02, j...@dockes.org wrote: I wanted to separate the commit that modified existing mpd files from the commits that added new code. I don't follow this argument. Adding a new source code file and registering it in Makefile.am belongs together, that's an operation that cannot be splitted. Only when you require modifications to other parts of MPD as preparation for your feature, then this must be a separate commit. For example, when you need one more parameter/method in an existing API declaration or function prototype, or when you add another generic utility library. I wonder if you will actually want to keep this commit history anyway. Maybe the best approach will be to wait for a reasonably stable version (to be decided), decide if you want this at all, add the code in a single modification, and then switch to regular maintenance/modification commits. Tell me when you feel it should be merged, and then I'll review the branch you cleaned up. It's somewhat cumbersome to review this branch in the current form. Hint: learn about stgit. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using MPD to play music from an UPnP Media Server
On 2013/11/04 19:33, j...@dockes.org wrote: - If nobody is interested in actually trying out the function (as seems to be the case), the merge won't be a concern :) I can't - I have no UPnP hardware. Therefore, I have exactly zero personal interest in the feature ;-) -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Custom music tags can now be entered into wavpack (ape) files but how to i get my db to update?
On 2013/11/02 00:02, Bearcat M. ??ándor bear...@feline-soul.com wrote: Folks, Recently bug 3843 ( http://bugs.musicpd.org/view.php?id=3843 ) was resolved as fixed. If i want to take advantage of this, what do i need to do? You need to read the protocol documentation. Since this is the developer mailing list, I assume you want to develop MPD or develop a client, therefore you know what I mean. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Request for git account
On 2013/10/31 09:54, Rafi B. justr...@gmail.com wrote: Name: Rafael Bodill Email: justr...@gmail.com Username: rafi Projects: gmpc, libmpd Public key attached, thanks! :) http://git.musicpd.org/cgit/rafi/gmpc.git/ http://git.musicpd.org/cgit/rafi/libmpd.git/ -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] ProxyDatabase plugin
On 2013/10/20 20:11, Jean-Francois Dockes j...@dockes.org wrote: The thing that made me believe this is the recursive field of the selection parameter to Visit, and the fact that the existing implementation in ProxyDatabasePlugin.cxx was recursive. Actually, recursive does not mean the implementation is technically required to implement a recursive function; it means the caller wishes to search in depth, find songs in sub directories and not only the one directory that was specified. How the implementation accomplishes that is another story. No, you don't even need a recursive tree walk there. You can still pass all the criteria to MPD - all but one: the base URI, because the MPD protocol can't limit a search to a sub directory. Ok, that's great. So the tree traversal aspect can be completely ignored, and everytime recursive is set, we are actually always performing a search, to be implemented as seen fit ? Yes. Max -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Tags in OGG httpd stream
On 2013/10/11 05:12, Ben Boeckel maths...@gmail.com wrote: the tag chunk is dropped because chunk-length is 0 for it. A patch which fixes the issue is attached. Merged, thanks. Sorry for letting you wait for so long. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] ProxyDatabase plugin
On 2013/10/11 16:26, j...@dockes.org wrote: Hi, I have fleshed out the code inside ProxyDatabasePlugin.cpp so that it now works. Your patch is hard to read because it's all in one big undocumented chunk. Please split the patch into smaller pieces and document the API changes. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] YouTube support plugin
On 2013/10/12 16:38, Oleg Omelyusik oleg.omelyu...@gmail.com wrote: Hello everyone, I've started implementing YouTube (and maybe some other same services in future) support plugin. (I saw feature request on MPD's bugtracker which were submitted a year ago http://bugs.musicpd.org/view.php?id=3598). At this moment valid title isn't displayed in the playlist (there is just a video url) and a user can't choose quality of the video.Work with YouTube implemented in the separate library (you can it find here: http://github.com/oleg-omelyusik/GSSlib). Your library fails to build: gcc -c -Wall -Wextra -MMD tools/test.c -o tools/test.o tools/test.c:4:17: fatal error: gss.h: No such file or directory Installation is cumbersome, because the install target requires be to override both LIBDIR and INCLUDEDIR. The library's API is completely undocumented. Indentation in your configure.ac changes is wrong. Your default is enable_gss=auto but that value is nevery handled; it is considered the same as no. Does linking the MPD binary really work with that plugin? I mean, you explicitly disabled appending -lgss to $LIBS - but the Makefile never adds the flag. I did not test. You disabled error handling in configure.ac. What is the point of calling AC_CHECK_LIB when you ignore the result? configure.ac should only check for libgss if libcurl was enabled before. You should not use -lcurl because CURL may require more flags to find libcurl.so (using curl-config / pkg-config). +/* necessary because libavutil/common.h uses UINT64_C */ +#define __STDC_CONSTANT_MACROS Huh, you're not using libavutil! Your input_gss_read() does not fill the Error. Maybe because libgss has no (documented) way to obtain error information? Why do you say your stream is seekable when all you can do is rewind to offset==0? And not even that is useful; all you do is close the inner object and reopen it. If that was useful, the MPD core could do it was well with any input plugin. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH 1/2] ConfigData: Add support for signed integers
On 2013/10/19 15:38, Sebastian Thorarensen se...@naju.se wrote:
+unsigned
+block_param::GetUnsignedValue() const
+{
+ long value2 = GetIntValue();
This explicitly limits the range of unsigned integers to 2^31. Why
that?
I admit that the existing code is bad as well, by using strtol() when
sizeof(long)==4 on i386, and that should be improved. But your change
makes it even worse, by enforcing that limitation on all platforms.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH] decoder/mikmod: Add loop configuration parameter
On 2013/10/18 04:12, Sebastian Thorarensen se...@naju.se wrote: Hi, This patch allows the user to configure the mikmod decoder plugin to loop modules. It adds a configuration parameter to the mikmod decoder called loop which can be no (the old behaviour, default) or yes to allow modules to use backward loops. Please consider applying this patch. Merged, thanks. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Segmentation fault in master/HEAD when launching mpd --no-config
On 2013/09/26 17:19, Jean-Baptiste Denis j...@jbdenis.net wrote: Hello, I was playing with the last git version of mpd when I encountered a segfault simply by lauching : mpd --no-config The problem seems to be the dereference of the param variable in the DatabaseGlobalInit function call of glue_db_init_and_load function in src/Main.cxx. Indeed, a nullptr check was missing. Fixed it. Next time, please use the bug tracker: http://bugs.musicpd.org/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] 24 bit output from mp4ff and mpg123 plugins
On 2013/09/12 07:37, Ian Scott i...@polpo.org wrote: I've (trivially) patched the mp4ff plugin to provide 24 bit output. Also, libmpg123 is also capable of 24 bit output so that plugin could also be patched as well. Is this something that would suitable for general use? I have noticed that the MAD plugin provides 24 bit output. Many people have 24 bit-capable DACs in their computers these days due to the near-ubiquity of HDA audio. It's not like those extra bits are going to be dropped on the floor on most systems. Then again, the ability of most people to tell the difference between 16 and 24 bit audio is probably quite small. Yes, that would be interesting. libmad provides 28 bits, so a few years ago I figured it would be useful to drop only 4 of those instead of 12. I'm not sure how much that gains. I thought it would avoid rounding errors, and I thought it would bring a better approximation to the acoustic model implemented by MP3. Max -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] tilde paths in config file
On 2013/09/05 21:01, Maarten de Vries maar...@de-vri.es wrote:
While patching this in, I also noticed that tilde paths weren't properly
parsed in the latest git version. For example: `~/.mpd/database' became
`/home/maarten/~/.mpd/database'. I also fixed that by mostly replacing the
old function. The version in my patch uses std::string and iterators rather
than old C strings and C functions. It's C++ now after all and I found it
much easier that way.
This patch looks VERY confusing because you mixed two different things
in one patch. One is the rewrite, the other is the bug fix.
I don't even see an advantage of using std::string here (the
disadvantage is increased bloat). The code doesn't get smaller or
more readable by using std::string, it gets only smaller because you
merged the default user / explicit user branches.
This line:
std::string user(user_start, user_end);
is the equivalent of the old:
g_strndup(path, slash - path)
No difference in readability.
What I don't understand is why you allocate memory for a second copy
of path. The original code avoids that.
Btw., this:
if (!user.size()) {
is more bloated and less readable than:
if (user.empty()) {
.. because it forces the std::string to determine the size, and the
latter does not.
Max
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Remove duplicate optimisation for volume
On 2013/08/16 12:27, Matthias Larisch m...@matthias-larisch.de wrote: While I agree on the second case we save one memcpy on the first case. You got it, and that's the reason we have a similar optimisation in two code locations. The two optimisations are not equivalent and neither can be removed. In my opinion we could save a memcpy for each filter by removing the const attribute of first parameter... Maybe we need one memcpy at start of filter chain (not sure) but not at every filter. What would we gain from this API change? Maybe then we could merge the two optimisations as Andrew suggested, but that's negligible. On the other hand, we'd need yet another buffer and yet another copy, even if the whole filter chain does nothing. I'd like to pay for (copy) overhead only if necessary. If the user wants software volume / replay gain, then he'll get it, at a certain cost. But those who disable those features shall not pay the price for features they don't use. Therefore, the fast path through the filter chain that simply returns the unmodified input buffer is there to stay. Max -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH] Fix build with FFmpeg 2.0.
On 2013/08/07 13:48, Alexis Ballier aball...@gentoo.org wrote: not much more than the current code that does it for each packet (there's usually only one frame per packet) The difference is: it's allocated on the stack currently. The computational cost of a stack allocation is negligible, and there's no need for cross-thread synchronization. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] MPD website unreachable?
On 2013/07/04 14:59, zw g pekingmas...@gmail.com wrote: Dear List, From here China, i can access the official website of MPD at: http://www.musicpd.org/ There has been a massive amount of spam from China and Taiwan in the past few days, and our admin took a very desperate measure and blocked everything from there. I hope we can restore access soon. Max -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] aMPD: MPD on android
On 2013/07/03 17:47, Thomas Guillem thomas.guil...@gmail.com wrote: I dropped my finish() patches by error (a wrong git stash clear) when I decided to use the easy way. If you want, I can have a closer look but maybe I should wait for your port to C++, no ? MPD is already ported to C++, most of it. However lots of GLib references remain. Why did you choose the (outdated) stable branch for your development? I guess you'll face a lot of unnecessary work when you port your work to master. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] development: master or v0.17.x
On 2013/06/25 16:27, jsai...@cs.brown.edu wrote: I've been poking around with adding some features to mpd. (In particular, allocating the queue dynamically, instead of statically allocating O(max_playlist_length) memory.) Are you sure this is really better? I mean, seriously? Dynamic allocation causes heap fragmentation, and may result in more memory being wasted than the static allocation. The static allocation *should* only allocate physical memory when the queue really grows that large; until then, the kernel maps a single zero page. (If that's not what's happening currently, it is easy to optimize.) Should I be basing patches on v0.17.x or master? master. v0.17.x is only for bug fixes, the branch is frozen. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] NULL pointer vs bool false confusion
On 2013/05/27 19:37, Matthias Drochner m.droch...@fz-juelich.de wrote: there are some places in the mpd-0.17.4 sources where a false is used instead of a NULL pointer. See the attached patches. Good catch, merged. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [patch] allow custom cookie path for pulse outputs
On 2013/06/19 23:54, Alexander Sulfrian alexan...@sulfrian.net wrote: I created a patch to specify a custom cookie path for a pulse output. If you have multiple pulse outputs it could be difficult to synchronize all the pulse cookies. The whole point of your patch is to have multiple pulse cookies, but that's exactly where your patch fails: it's not thread-safe in the presence of multiple pulse outputs, is it? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH] fix overwriting bitrate with signal type
On 2013/06/19 10:53, Matthias Larisch m...@matthias-larisch.de wrote: I recently opened a bug: http://bugs.musicpd.org/view.php?id=3787 The main problem is that opus encoder config for signal overwrote bitrate setting. Appended patch fixes that. Merged. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATH] Prevent mpd from hanging while playing DSDIFF files
On 2013/04/29 13:53, Jurgen Kramer gtmkra...@xs4all.nl wrote: This patch prevents MPD from hanging when playing a DSDIFF file which has a DSD data chunk size not dividable by 4. http://git.musicpd.org/cgit/gtmkramer/mpd.git/commit/?id=e396f7f649cfd10ac2b0939f4eb98c4d5048d9c7 This issue only appears when using DoP (ie dsd_usb = yes). I don't understand the problem nor your patch. Please clarify. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Various improvements for master branch
On 2013/05/12 19:15, Denis Krjuchkov de...@crazydev.net wrote: Also added two changes with C++ conversion: All merged, thanks. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [patch] allow custom cookie path for pulse outputs
On 2013/06/24 18:35, Alexander Sulfrian alexan...@sulfrian.net wrote: oh thats true. Maybe we want simply lock this region. I reworked the patch and add a static Mutex to the PulseOutput struct. So that the lock should affect all pulse outputs but nothing else. That's even worse: if one Pulse server does not respond, all others have to wait, too. Hope that this is fine. If not please give me advice how to make the code thread safe. Don't use environment variables to pass data to a library. If libpulse doesn't support that, we're out of luck, and your feature cannot be implemented properly. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Pull request: Pipe Output Plugin: Pass environment variables to the pcm stream
On 2013/04/13 03:49, Mark m...@iinet.net.au wrote: Also, your code sets environment variables in the MPD process, but this should better be limited to the new child process only. work in progress Ok, tell me when you're done. Keep in mind that refactoring should be a separate commit. Don't mix refactoring and new features in one commit. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Pull request: Pipe Output Plugin: Pass environment variables to the pcm stream
On 2013/04/12 10:00, Mark m...@iinet.net.au wrote: Passes 3 environment variables (channels, bits, rate) to stdout for use by the next process in the pipe (eg SoX). Please pull: git://git.musicpd.org/quad/mpd.git master Identation uses spaces instead of tabs, please fix. Why these variables, why not string literals? Using buffers adds unnecessary overhead, because each call allocates space on the stack and copies the string literal there. + char rate_str[]=rate; Also, your code sets environment variables in the MPD process, but this should better be limited to the new child process only. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] AArch64 support
On 2013/03/23 08:14, Jamie Nguyen j...@jamielinux.com wrote: Hi, Some of us at Fedora are working hard on 64 bit ARM support. I noticed that you currently use autoconf 2.68. Support for AArch64 was introduced in autoconf 2.69, so would it be possible for you to migrate from to 2.69? That would be very much appreciated! The new MPD release tarball was built with autoconf 2.69. But do you really care how the tarball was built? I mean, you can always call autoconf again before building a package. That's what Debian does in many source packages. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH] fix broken --disable-documentation in configure.ac
On 2013/03/31 22:28, Zoltan Gyarmati mr.zoltan.gyarm...@gmail.com wrote: Hi Max, when building libmpdclient with --disable-documentation, the configure script fails: Merged, thanks. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Request for git account
On 2013/03/28 23:36, Mark m...@iinet.net.au wrote: 1. real name: Mark Bayley 2. email: m...@iinet.net.au 3. user name: quad 4. Project: MPD 5. SSH key attached http://git.musicpd.org/cgit/quad/mpd.git/ Sorry for the delay - I was on vacation. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH 1/3] ffmpeg decoder plugin: refactor the decoding functions
On 2013/03/27 17:38, Anton Khirnov an...@khirnov.net wrote:
Move some variables shared between multiple functions to a struct so the
functions don't need too many parameters.
Move initializing the decoder into a separate function to improve
readability and reduce cleanup code duplication.
Emits clang compiler warning:
src/decoder/FfmpegDecoderPlugin.cxx:511:45: error: missing field
'avctx' initializer
[-Werror,-Wmissing-field-initializers]
struct ffmpeg_decoder_context dec = { NULL };
Here, C++ is different from C.
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] [PATCH] ffmpeg decoder plugin: do not allocate an AVFrame on stack.
On 2013/03/22 07:05, Anton Khirnov an...@khirnov.net wrote: AVFrame must be allocated with avcodec_alloc_frame(). Merged, and backported to v0.17.x. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Compilation for embedded devices
On 2013/02/24 18:33, H. Fritsch fritsc...@in.tum.de wrote: Hi, I tried to compile mpd for some embedded devices (Fritz-Box/Freetz and Android) and ran into some problems which I had to fix. Have a look at https://github.com/rumpeltux/mpd/commits/android if you???re interested or feel free to pull and cherry-pick directly from https://github.com/rumpeltux/mpd.git. I've picked a few obvious changes, but didn't understand the other fixes. Please explain. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Compilation for embedded devices
On 2013/02/27 21:32, H. Fritsch fritsc...@in.tum.de wrote: The signalhandlers: apparently there are some non-windows systems that don't know about struct sigaction, that?s why I modified the detection there (from sigaction(2) manpage): Which ones? Are they relevant for MPD? These are standard POSIX functions, I expect them to be available everywhere. src/resolver.c didn't include sys/socket.h or netdb.h, probably because G_OS_WIN32 may have been defined. Not sure :/. Which symbols require these headers on Windows? getaddrinfo() not: http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520%28v=vs.85%29.aspx src/event/SocketMonitor.cxx redefines ssize_t for no obvious reasons and was therefore causing compiler errors at some other place. Which compiler errors? It does not redefines ssize_t, it defines its own ssize_t; ssize_t requires including sys/types.h, it's not a standard C type. For the NaN-issues, I?ve actually no idea why std::isnan etc is not available when compiling for android, so I just removed the prefix, but this likely breaks other stuff. Maybe someone with more experience can help here? ;) Did you try the gcc 4.7 toolchain? Your script refers only 4.6. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] MPD crash in memory constrained embedded system
On 2013/02/08 17:12, Timur Aydin t...@taydin.org wrote: So my question is, how does MPD do the indexing of the database? Does it build the entire index in memory and saves the index after finishing? Yes. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Build failure again
On 2013/01/28 15:31, Alexander Sack pisym...@gmail.com wrote: In file included from src/decoder/mp4ff_decoder_plugin.c:29:0: /opt/local/include/faad.h:32:9: note: #pragma message: please update faad2 include filename and function names! src/decoder/mp4ff_decoder_plugin.c: In function 'mp4_decode': src/decoder/mp4ff_decoder_plugin.c:240:27: error: dereferencing pointer to incomplete type src/decoder/mp4ff_decoder_plugin.c:245:20: error: dereferencing pointer to incomplete type src/decoder/mp4ff_decoder_plugin.c:197:15: warning: variable 'initial' set but not used [-Wunused-but-set-variable] Good point. Turns out that none of my remaining chroots has libmp4ff, and I didn't notice this problem. I had to remove a few chroots from my regular MPD build test because their gcc was too old. Since libmp4ff has been obsolete for many years, it's about time to remove this plugin. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Connection issues with master
On 2013/01/27 08:56, Denis Krjuchkov de...@crazydev.net wrote: I've made improvements to the code and documentation. Also there is one more patch. Please take a look. I've merged the first two. I stopped at the MPD_PATH_MAX_UTF8 definition because I could not see an explanation for the value. What is this worst case that requires 4*MPD_PATH_MAX? -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Connection issues with master
On 2013/01/27 17:38, Denis Krjuchkov de...@crazydev.net wrote: 27.01.2013 22:18, Max Kellermann ??: I've merged the first two. I stopped at the MPD_PATH_MAX_UTF8 definition because I could not see an explanation for the value. What is this worst case that requires 4*MPD_PATH_MAX? UTF-8 requires at most 4 bytes for single character. So if there is some encoding that could represent those large characters as single byte conversion to UTF-8 would require 4x bytes. You have described that a character may be represented by 4 bytes, but that does not really answer my question. That upper limit would apply if a string holding MPD_PATH_MAX 4-byte characters must be represented. When will that happen? What is the real meaning of this MPD_PATH_MAX_UTF8 value, in general? Is it an upper limit imposed by MPD? By the operating system? What will it be used for? I'm asking specifically because on Linux, the name limit is not measured by number of characters, but by number of bytes. That is because the kernel does not know or care about characters. On Linux, this constant doesn't make a lot of sense, and I'm trying to imagine a use case where it would make sense. What I don't want is some obscure constant floating around in a header file that people will start to use without understanding the math behind it. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Connection issues with master
On 2013/01/24 21:38, Denis Krjuchkov de...@crazydev.net wrote: I've prepared few more patches with Path class migration. Path: ToUTF() returns std::string removes the ability for the caller to check for errors. Maybe checking for an empty string might work, as paths may be expected to be non-empty, however you removed documentation on this. This should be a well-documented condition. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FileSystem: new library for Path-friendly file system routines
On 2013/01/21 19:51, Denis Krjuchkov de...@crazydev.net wrote: 22.01.2013 0:45, Max Kellermann ??: This gives me a warning on WIN32: No problem, I'll redo the patch. Anything else? No, patch looks good, I didn't check the second one yet. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FileSystem: new library for Path-friendly file system routines
On 2013/01/21 20:00, Denis Krjuchkov de...@crazydev.net wrote: Some headers are defined via mpd_headers, some via src_mpd_SOURCES. At the moment I'm trying not move them between these variable. What should I do? mpd_headers is old cruft, don't use it. I could merge mpd_headers into src_mpd_SOURCES, but I'm too lazy. So I just use src_mpd_SOURCES for new stuff. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FileSystem: new library for Path-friendly file system routines
On 2013/01/21 20:13, Denis Krjuchkov de...@crazydev.net wrote: I've pushed the fixed version. First patch merged. Second patch is broken because test_DumpDatabase_SOURCES still contains the old src/Path.cxx. I guess we could move those src/fs/ sources to another static library, let's say libfs.a. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/19 07:33, Denis Krjuchkov de...@crazydev.net wrote: Important thing for wrappers is error management: errno might be messed in between because constructing Path might change it. What are options here? Path::Null() does not modify errno. And Path::Null() shall be returned on error. No problem. Also I've forgot about logging. Should logs be UTF-8 too? What if logging is redirected to stderr. In that case FS encoded paths are expected. Log file is UTF-8. Logging to stderr is for debugging only, it's not a supported operation mode. If that turns out to be an issue, then the logging library must convert. In project I work on we tend to avoid writing abbreviations in all caps. For example HTML is spelled Html. This gives some better readability. My eyes blow on names such as FLACIOHandle. There are some corner cases like Io, Id (they don't look cool IMO). But can't we adopt this approach for some longer names (i.e. four or more letters)? FLACIOHandle would be FlacIOHandle. Anybody knows what FLAC means anyway, but Flac is more readable in identifiers. Yes, if you like Flac more than FLAC in camel-case names, I'm ok with changing it. (Id is an abbreviation, but it's not an acronym, therefore ID is wrong in any case.) C++ provides wrappers for standard C headers (e.g. cstdio for stdio.h). Are there any rules on them? I tend to use them, however they have serious disadvantage: it's hard to predict whenever some function would appear to std namespace. So should we dismiss those headers? I have never used the C++ wrapper headers, I don't know why they exist and whether using them has an advantage. Until somebody explains it to me, I'll keep on using standard C headers, but I wouldn't mind patches using C++ headers and std::. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/19 13:09, Denis Krjuchkov de...@crazydev.net wrote: I've played a bit with the code. It seems convenient to change Path::ToUTF8() to return std::string. I'd like to not introduce something like PathUTF8 class and use standard types where applicable. Agree. * We could predict max size for UTF-8 path name basing on MPD_PATH_MAX. I know there are lots of weird encodings out there, but likely the result string would not exceed MPD_PATH_MAX * 4. One character in UTF-8 occupies at most 4 bytes, so even extreme case this should be enough. Since the path is nul-terminated size could be even less: ((MPD_MAX_PATH - 1) * 4 + 1). Yes, that seems reasonable for temporary allocations. We should watch out for pointers that are stored permanently, these should not have permanent worst-case overhead. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FileSystem: new library for Path-friendly file system routines
On 2013/01/20 14:10, Denis Krjuchkov de...@crazydev.net wrote: Pushed slightly improved version: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=e6ed592b8aeb5025be0893ee99ff44e46a9ffd1c Thanks, that looks like a good start, I have merged it. What I don't like: - FileSystem.hxx includes all relevant system headers, and I would like to reduce header dependencies as much as possible; include special things like dirent.h only if you really want to read directory contents - ReadLink() should better return a Path object, and Path::Null() on error - CheckIsRegular(): for me, a name like IsRegularFile() sounds better - slightly disagree with Ben (but thanks for pointing out that potential problem): there should be some way to specify whether symbolic links shall be followed. Some callers may want to follow symlinks, some do not, and the database update has that configurable at runtime. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] FileSystem: new library for Path-friendly file system routines
On 2013/01/20 17:24, Ben Boeckel maths...@gmail.com wrote:
On Sun, Jan 20, 2013 at 17:14:12 +0100, Max Kellermann wrote:
- slightly disagree with Ben (but thanks for pointing out that
potential problem): there should be some way to specify whether
symbolic links shall be followed. Some callers may want to follow
symlinks, some do not, and the database update has that configurable
at runtime.
Maybe have a CheckFileExists (stat) and a CheckPathExists (lstat)?
I think that's too obscure. And doesn't scale: what about
CheckIsDirectory()? You can't apply the same solution here.
What about a bool parameter:
bool IsRegularFile(Path, bool follow_symlinks=true)
The compiler will make the stat/lstat choice disappear when a constant
value is passed. May use another wrapper:
static inline bool
StatFile(const Path path, struct stat st, bool follow_symlinks=true)
{
return follow_symlinks ? stat(path.c_str(), st) : lstat(path.c_str(), st);
}
(use native WIN32 functions on Windows)
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/18 12:30, Denis Krjuchkov de...@crazydev.net wrote: OK. Just let me know if you're willing to adopt this approach. If not I'll think about other possible solutions for improving Unicode support on Windows port. I'm ok with it. Please review my patch, and if you think it's correct, you may merge it and write more patches on top of it. I think compiler is going to call destructor which requires `this` parameter pointing to some memory location. Apparently it is not smart enough to generate destructor variant that is able to destroy the object stored in a register. The compiler can very well do that, it will even suppress the free() call (and let the destructor disappear completely) if it sees a NULL check before that. Yay for modern C++ compilers! The problem is when a Path object leaves the function and must be passed/returned to/from an extern. This is where the C++ ABI must be applied. -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/18 12:30, Denis Krjuchkov de...@crazydev.net wrote: 17.01.2013 19:08, Max Kellermann ??: I'm not sure. This missed chance for optimization is annoying, but the advantages may outweigh that. OK. Just let me know if you're willing to adopt this approach. If not I'll think about other possible solutions for improving Unicode support on Windows port. I have improved and pushed my Path patch. I guess there's still a lot of room for improvement. You are welcome to work towards using wchar_t for Path::value_type on Windows. -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/17 13:34, Denis Krjuchkov de...@crazydev.net wrote: 17.01.2013 16:40, Max Kellermann ??: Unfortunately, this means that a Path instance can never be passed in a register, it must always go the round-trip to memory and back. This adds overhead. Admittedly not much, but useless, and enough to annoy me. So you're going to refuse this approach? I'm not sure. This missed chance for optimization is annoying, but the advantages may outweigh that. Some overhead is unavoidable when using high-level features. Having non-trivial destructor provides automatic resource management which is impossible with raw pointers. Actually, C++ is a language that is extremely well at abstractions and syntactic sugar that cost nothing at runtime. This overhead would be avoidable! In this case, the compiler is too stupid to apply the optimization. Or the C++ ABI doesn't allow it, because it may not have been adapted to C++11 capabilities yet. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/16 11:42, Denis Krjuchkov de...@crazydev.net wrote: Some bonus thoughts: What if we start from different side and implement a wrapper (i.e. class FileName) that encapsulates actual file name string (no matter how it is stored internally)? What kind of path name would this class represent - MPD's internal path names (always narrow), or the external OS path names (sometimes wide)? Finding a good representation for strings is perhaps one of the most difficult things in C++, at least when you want to avoid overhead (and C++ is extremely good at giving you ways to avoid overhead, something which is not possible in higher-level languages): 1) a pointer to a C string (const char *) 2) an dynamically allocated buffer (e.g. std::string) 3) a fixed-size buffer (e.g. char[PATH_MAX]) Each of these has problems of its own. For example, (1) often cannot be used because somebody else needs to manage the memory pointed to. (2) can be a lot of overhead for the allocator. (3) is very fast, but wastes memory. I think this needs to be designed carefully, because I don't want MPD to grow into a bloated beast. Maybe we need to implement two (or all three?) of the above? This would require more effort, because there are other functions that deal with file names directly. For example composing path from multiple components. As far a I understand currently it's implemented via GLib routines. Since we're anyway migrating from it such reimplementation would be required anyway (some code might be directly imported from GLib I think). The GLib functions are not terribly sophisticated, they are merely a convenience. Having a class that has well-defined methods for path manipulation would be even more convenient. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/16 12:19, Denis Krjuchkov de...@crazydev.net wrote: 16.01.2013 17:00, Max Kellermann ??: What kind of path name would this class represent - MPD's internal path names (always narrow), or the external OS path names (sometimes wide)? This would contain OS path names. Which would add useless overhead to non-Windows. MPD's internal path names are always const char* (currently), and stuffing that into a std::string will always allocate memory. There's no optimization for that. (C++11 will only help with passing the temporary instances around, but will not help with construction overhead.) -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/16 12:59, Denis Krjuchkov de...@crazydev.net wrote: Well, I think this would not be significantly different from current situation. If I'm understanding right mapper layer anyway allocates memory for transitions between internal UTF-8 and file system encoding. Even if file system encoding is UTF-8. I'm just proposing change of mapper interface from char* - char* to char* - FileName which gives benefit in additional type system check for possible messing between two representations. So overhead is really for additional code correctness which I think is a good goal to sacrifice some cycles. It doubles the overhead. For something that is only necessary for one weird operating system that can't represent file names in standard strings. And no, there isn't even any additional correctness verification to justify it. You can still pass MPD's internal path names to standard I/O functions. What I suggest: use that path class for *all* file names internally. All conversions UTF-8 - path must be explicit (via the mapper library), and all uses for system calls must be reviewed. There is no added overhead here. Once that is complete, you can change the storage of that class from char to wchar_t for WIN32, and the compiler will help you spot the code locations that must be converted to wchar_t system calls. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/16 13:42, Denis Krjuchkov de...@crazydev.net wrote: 16.01.2013 18:25, Max Kellermann ??: It doubles the overhead. Could you provide an example? I can't really imagine how this doubles overhead. First you map UTF-8 to filesystem path (e.g. via map_uri_fs()), which duplicates the string. Then for conversion to your path class (for passing to a system call), std::string duplicates the string again. Makes two allocations instead of one, even on sane operating systems. Storage class for what? For protocol FileName (which is always UTF-8 anyway)? The protocol doesn't have path names. There are these file:// URIs but they are not real path names, even though they technically represent ones. Therefore, protocol strings shall be char* or something based on it. char* shall always be UTF-8. Or for real file names which you want to keep as char*? If second this would introduce pre-processor weirdness in the code that uses stdio and friends because each such call would require #ifdef. In any case, you need some glue that selects narrow or wide system calls. You can't avoid that, can you? -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/16 14:42, Denis Krjuchkov de...@crazydev.net wrote: What would map_uri_fs() look like? We are gived UTF-8 URI and need to return std::string-based type. First we call character conversion routine. This allocates some memory. Then we copy the result to our std::string-wrapper (aka Path). This employs additional copying, don't it? Finally we free the our char* buffer and return Path. I guess you can convert right into the std::string, can't you? (Maybe GLib cannot, but I mean technically it is possible.) But it's even easier; with my idea, you don't need to transfer ownership at all. Let some code do the talking: Well this is exactly what I've proposed from start of our discussion (starting from Some bonus thoughts). And you initially disagreed with it. Ok, I may have misunderstood/misread. I thought you were keeping path_fs as it is, and only convert to OS encoding when a syscall is invoked. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Pull request for ticket #3650
On 2013/01/16 19:15, Brice Jaglin bjag...@gmail.com wrote: Hi, I filed an issue earlier today, but after digging-in into the code, I figured out an easy fix myself and just pushed it to a github clone. https://github.com/bjaglin/mpd/commit/a84774fd46e4f3b6147bfd3d19ff4841bde8c98d Merged, thanks. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/15 18:21, Denis Krjuchkov de...@crazydev.net wrote: I've proposed this feature some years ago. Finally got some passion to implement it. Here is the short story: Windows supports Unicode via UTF-16 (wchar_t), MPD handles file names as char* strings. What is really the problem you're trying to solve? I mean, internally, MPD does not assume path strings are UTF-8. MPD assumes they are in the native filesystem character set, and each time a file name gets copied over the wire, it is converted to UTF-8 (because the protocol is defined to be UTF-8). Is the problem that the native 8 bit charset is not capable of representing all possible wchar_t file names? If that's the case, then I guess we should be using TCHAR. -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/15 21:13, Denis Krjuchkov de...@crazydev.net wrote: 16.01.2013 2:05, Max Kellermann ??: Is the problem that the native 8 bit charset is not capable of representing all possible wchar_t file names? If that's the case, then I guess we should be using TCHAR. Yes, the problem is that some characters could not be represented this way. UTF-8 approach is less pervasive and UTF-16 - UTF-8 conversions shouldn't hurt performance too much. Hm, ok, I think wrapping everything in our own functions is not exactly the most beautiful solution, but will do. (It creates a third character set: UTF-8 for data/protocol strings, internal FS charset, external FS charset) Though I believe your change in server_socket.c is wrong. The narrow path is used in s_un.sun_path, but you delete the wide path name in the u_unlink() call. Anyway, that part of the MPD code isn't portable to Windows. What's your plan for path names that are passed to other libraries? Will MPD work for some codecs, but not for others? Known bug/limitation? -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] UTF-8 file names support for Windows
On 2013/01/15 21:55, Denis Krjuchkov de...@crazydev.net wrote: 16.01.2013 2:38, Max Kellermann ??: Hm, ok, I think wrapping everything in our own functions is not exactly the most beautiful solution, but will do. (It creates a third character set: UTF-8 for data/protocol strings, internal FS charset, external FS charset) Well I was thinking this way: external FS charset is really not important for the most of the code. Let's consider this some implementation detail for ustdio.cxx and Win32Util.cxx The rest of the code could assume that FS charset is UTF-8. What I would like to have in the long run is some compile-time verification on correct use. This is complicated enough already with just two different string types, and I tried adding _utf8 / _fs suffixes to variable names. Maybe some sort of C++ string wrapper that cannot be implicitly casted to the other wrapper. You're right. I've started with changing all the functions to their u_ counterparts. Then reverted some changes for the files that are not to be compiled on Windows in a whole (such a daemonizing support code). There are corner cases like in server_socket: some functions are to be compiled on Windows but some are not. Do we need to use wrapper in functions that are ifndef WIN32 ? If some day such function will became compilable on Windows somebody might easily forget to add the prefix. This would introduce the bug. My complaint was not actually about POSIX-only code - it is ok to use u_* wrappers on non-portable code. My complaint was that the path name was not used consistently; one path string was passed to u_unlink(), and the very same pointer was copied without conversion to the sockaddr_un. Since it's impossible to use this consistently (because there's no wide sockaddr_un variant), I suggest not changing this, or adding a code comment explaining it, to aid the guy who happens to be porting this feature to Windows one day. Some libraries can accept file descriptor or FILE*. So we can pre-open such files for them using our u_ wrappers. This requires some thinking how to avoid adding many new methods for decoders (i.e. decoder_plugin_fd_decode, decoder_plugin_FILE_decode). Extending the decoder API would not be necessary - each decoder plugin could implement the file_decode method and open the path_fs instead of passing it to the external library. -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Some more fixes for master branch
On 2013/01/13 10:39, Denis Krjuchkov de...@crazydev.net wrote: Hi all, Win32Main.cxx: more clean shutdown WakeFD.cxx: use two sockets instead of pipe on Win32 ClientList.cxx: copy client list before iterating The last is merely a quick fix to allow further development. Probably some other data structure could be used for client list. Feel free to drop this. All merged. Though we should find a better solution for the last patch. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Provide fall-back strndup() implementation
On 2013/01/11 09:04, Denis Krjuchkov de...@crazydev.net wrote: DatabaseLock.cxx defines global db_mutex which could not be used before GLib threading routines are initialized in main(). I don't understand. It's not a GLib mutex! What's wrong with it? -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Provide fall-back strndup() implementation
On 2013/01/11 09:31, Denis Krjuchkov de...@crazydev.net wrote: 11.01.2013 14:25, Max Kellermann ??: I don't understand. It's not a GLib mutex! What's wrong with it? I'm trying Windows port which uses GLib mutex/condvar. Those don't work until g_thread_init() is called. Oops. Yes, now I understand. -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Improve configuration status results
On 2013/01/10 09:54, Denis Krjuchkov de...@crazydev.net wrote: One more minor fix. This time it's against master branch. I've added some missing libraries. Also Opus codec had different names in encoder and decoder sections. Now it's consistently named Opus. Merged, thanks. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 11:06, Denis Krjuchkov de...@crazydev.net wrote: As I've saw in git MPD is still going to use GLib's mutex/condvar implementations for Windows. Actually, I'd love to use std::mutex et al, but that's not available on the mingw-w64 version shipped in Debian. I could try a newer version, but my goal is to make it buildable with Debian tools. However the Linux port of MPD doesn't use std::mutex because it (the GNU libstdc++ implementation) adds overhead. The lock() method needlessy checks the return value and throws an exception on error, even when exceptions are disabled. Very small overhead, but still unnecessary. May be we could just take pthreads-win32 instead? http://sourceware.org/pthreads-win32/ That would be another dependency, wouldn't it? Yes, we could do that. My rationale for removing GLib was to make porting to Android possible, and therefore GLib will be removed from the normal Linux build first. Removing it from Windows is not my goal, but pthread-win32 sure could help with that. Another idea I had was use the native WIN32 condition variables, which requires Windows Vista or newer. I'm not sure if that's a problem. I mean, Windows XP is 13 years old and its support will finally expire in just a few months. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052.aspx This will be less overhead than pthreads-win32, because it doesn't attempt to emulate a foreign API. (Next problem is that the prototypes for this API are not available in Debian's mingw-w64 *sigh*) Max -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 11:43, Denis Krjuchkov de...@crazydev.net wrote: This might be a good idea since Vista provides other useful APIs. I don't care much about Windows. For many years, I was careful about requiring Vista+, because I thought many users were still happy with XP, and I did not want to force anybody to buy a new OS version. But I guess the times of XP are over. Requiring Vista+ is ok for me if nobody else objects. Such as poll() implementation: http://msdn.microsoft.com/en-us/library/ms741669%28v=vs.85%29.aspx I'm not yet sure if we will need this. The next big step is eliminating the GLib event loop. I wouldn't like to reimplement this from scratch, rather use libevent (which I have been using a lot in other projects), but I'm not sure how portable libevent really is. I use Kubuntu 12.04. It has condvar API available in mingw-w64. Which mingw32-runtime version is that? I have 3.13-1, and it does not provide CONDITION_VARIABLE. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 11:52, Max Kellermann m...@duempel.org wrote: Which mingw32-runtime version is that? I have 3.13-1, and it does not provide CONDITION_VARIABLE. Oh, I was looking at the wrong directory. Should be mingw-w64-i686-dev, and indeed CONDITION_VARIABLE can be found there. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 12:13, Denis Krjuchkov de...@crazydev.net wrote: Probably separate socket pair could be used instead of pipe. This would at least eliminate extra-thread. Why not. Good luck I factored out that code into the class WakeFD (for adding Linux's eventfd()). We can now easily exchange the pipe() call with socketpair() on WIN32. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 12:24, Denis Krjuchkov de...@crazydev.net wrote: Last time I saw it MPD used int type for sockets. Windows API actually defines a SOCKET type which a typedef for UINT_PTR. WTF? From my observations socket handles grow sequentially from small numbers to higher. This makes error unnoticeable. What is the practical problem then? After MPD has accepted its two billionths client, further connects will fail? I could try to provide a patch for mpd/mpc/libmpdclient but not sure what's the best way to do it. Define separate type (i.e. mpd_socket) that always is a typedef for correct socket type. Or just #ifdef in each particular usage? In MPD, there should be a class wrapping a socket descriptor, which hides implementation specific details. Also this might break the API of libmpdclient and I'd like to avoid API breaks for other platforms. On Linux, we could easily use symbol versions, but on Linux this isn't a problem anyway. I don't know if DLLs can have versioned symbols. But on Windows, we could add another symbol for the SOCKET type, and make all functions with int static+inline wrappers which cast to SOCKET and call the new function. Therefore, binaries which were compiled with the new headers will use the new symbols, and old binaries will continue to use the old symbols (which will continue to exist as long as 2 is the major version). -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 12:32, Denis Krjuchkov de...@crazydev.net wrote: Was it meant to be g_strndup()? mingw lacks strndup() at the moment. Actually, I wanted to avoid using GLib in new code. Since strndup() is a standard API, not a GNU extension, I presumed it was safe to use.. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 13:06, Denis Krjuchkov de...@crazydev.net wrote: So practically this requires adding one more function for each function that deal with sockets? Yes. That's three: mpd_async_new(), mpd_async_get_fd() and mpd_connection_get_fd(). If new functions would be implemented as static+inline wouldn't it break the ABI for already compiled programs? Because such functions exist only at compilation stage and are not present in the compiled .DLL True, this is where it gets hairy. There must be three versions of mpd_async_new(): - the new symbol mpd_async_new_SOCKET with SOCKET parameter (shall never be explicitly called by applications, part of the ABI but not the API) - the inline function mpd_async_new with SOCKET which calls mpd_async_new_SOCKET (this being the only caller of mpd_async_new_SOCKET) - the old symbol mpd_async_new with int which also calls mpd_async_new_SOCKET (after casting to SOCKET) - to satisfy the old ABI -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 13:24, Denis Krjuchkov de...@crazydev.net wrote: Could the suffix be something like _win32_socket instead of _SOCKET which is ugly and anyway does not clarify what it's for? Yes. That was just a quick example. This is truly crap, and I'm not even sure this is worth fixing. If there are practical problems with int/SOCKET, I wonder if making it libmpdclient2b.dll would be a better solution. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Using GLib for threading primitives on Windows?
On 2013/01/10 13:32, Denis Krjuchkov de...@crazydev.net wrote: GLib uses different approach as you know. They provide separate APIs for dealing with sockets for Unix and Windows. This requires user to write several #ifdef's but makes things clear. Couldn't we consider similar approach? This looks like the worst possible solution. Sure, it reduces the complexity of a possible libmpdclient solution, but that complexity has not disappeared - it is just being moved (and multiplied) to every single application. And it doesn't even have much to do with our current problem. Our problem is that we didn't use the proper data type for sockets on WIN32, and we can't fix this without modifying the ABI. Diverting the API (not the ABI) is just a kludge to move the responsibility to somebody else (those who didn't make the mistake in the first place). -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Minor fixes: improve libgme detection + add missing file in dist
On 2013/01/09 09:38, Denis Krjuchkov de...@crazydev.net wrote: That's it. Patches are submitted via git: Merged, thanks. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] audio format information timing with idle
On 2013/01/07 14:11, Timur Aydin t...@taydin.org wrote: Hi, I have an application that listens to mpd status changes using idle and writes the current mpd status onto a hardware display. After issuing a play command, mpd immediately notifies the player status change. At that point, I read the status of the player, but the status does not include any audio format information. But mpd just told me that it started playing. If I wait 1 second after receiving the player status change notification, then the status includes the audio format information. I have tested with both internet radio stations and with stored audio files, same result. I think that's a bug, and the event should be delayed until MPD knows all the details. Please write a ticket. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] audio format information timing with idle
On 2013/01/07 21:00, Timur Aydin t...@taydin.org wrote: Actually, both of these statuses are valid and valuable. The first can be interpreted and displayed as a buffering... and the second can be displayed as playing. So it seems it would be better if we add a new player state called buffering. This way, a client can deterministically know what MPD is doing and display its status accordingly. Let me know what you think about this... Yes, that sounds like a good idea. Though there should not be a special state buffering, as this reveals too much of MPD's internals (which may change at any time). It's enough to be aware that while MPD starts playback, the audio format may not be available until playback initialization has completed. Clients should also not rely on getting two notifications, because the two PLAYER events will be merged when the client is slow. That's a feature, not a bug. If you don't ever see the state playing, but no audio format yet, that's perfectly ok. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Glib warnings
On 2013/01/02 16:31, Alexander Sack pisym...@gmail.com wrote: I started to remove the warnings with a lot of #if conditionals but I was curious if the project plans to move the base version of Glib to 2.32 instead of 2.16? That would at least make the changes to mpd a lot less ugly. But I am not sure what are the implications of such a change (regression etc.). No. I consider these API changes a big regression, because they add overhead. Previously, a GMutex was just a wrapped pthread_mutex_t, and now I have to allocate it from the heap. It is more likely that we will migrate to std::mutex (C++11). Since the code base is (slowly) being migrated to C++11, the use of GLib is fading out. Back when we started using GLib, it was a great relief, but GLib has also caused a lot of trouble (e.g. when cross-compiling), and some of its APIs are just horrible to deal with (e.g. GSource). This ugly GMutex change was just the missing nail in GLib's coffin. Max -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
