Re: [Musicpd-dev-team] Regarding Windows builds of MPD
14.12.2013 0:10, Max Kellermann пишет: I'm all for fixing bugs in the stable branch, but if your idea of (2) is to backport the master code, then this is not my idea of a stable branch, and we're better off with (1). However my preference would be (3): fix only the regressions that made 0.18 unusable. Hi Max, I fully agree with your approach to stability, however situation is somewhat disastrous. Source of the problem is custom event sources (which are used everywhere in 0.18.x unlike for example 0.17.x). GLib expects event handle in GPollFD rather than socket descriptor. All hacks for constructing (and updating) correct GPollFD are already implemented in standard GLib event sources (i.e. standard IO channels). I've spent some time trying to understand what they do, but didn't succeed :-) I think implementing correct fix for 0.18.x by either copying internals of standard IO channels or changing MPD to use standard IO channels is unlikely to be considered stable anyway. Also I doubt that GLib implementation is correct in all sutuations. IMO it's just too tricky to do it well. It seems that case (1) looks like the best solution. -- Denis -- 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] Regarding Windows builds of MPD
14.12.2013 0:24, Sean McNamara пишет: Hi, Hi Sean, 1. For now, you make a tested build based on git master, which you have personally evaluated and find that it is mostly correct, except for any platform-independent bugs that are already known but not yet fixed. This basically constitutes downloading the latest commit from git master and trying out several features of the windows build; if it works, great, you can ship it once it meets your own personal criteria of what constitutes a good enough build. This would be the one and only Windows build until the next stable release of mpd, unless of course, some user decides on their own to build the code separately, which is their prerogative. That's practically how I've done it for 0.17.x. I've tested manually various audio file formats, various output plugins, etc. 2. Going forward, once the next stable mpd release is made based on git master, you would only need to provide updated builds for Windows when a stable release of the mpd source is officially released. This wouldn't involve any backporting, and seems like it'd be fairly minimal work on your part (relative to all the code changes you've made lately; thanks for that!). Again that's how it was done for 0.17.x. I'm willing to return to this practice when 0.19.x becames stable. Anyway my build scripts support three build sources: latest stable tarball, latest stable git and development git. I need this to do development of MPD itself because large part of building MPD for Windows is building lots of libraries that are not always buildable out of the box. So generally creating new stable branch of MPD requires almost no work at my side. -- Denis -- 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
I've pushed implementation of standard directories API. It does not support non-POSIX getpwnam_r/getpwuid_r yet, because I don't know how to test it. Please take a look. CommandLine: refactor config search, use standard directory API Main: use standard directory API ConfigPath: use standard directory API fs: implemented standard directories API TextFile: move to fs subsystem -- 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
Few more improvements + fix for starting with missing db file on Windows fs/FileSystem.hxx: don't define CheckAccess() with mode on Windows db/SimpleDatabasePlugin.cxx: don't use CheckAccess with mode on Windows fs/FileSystem.hxx: add CheckAccess without mode parameter fs/Traits.cxx: don't return drive path without trailing separator fs/Traits.hxx: introduce PathTraitsXXX::IsDrive function fs/Charset.cxx: replace \ with / when converting path to UTF-8 on Windows PlaylistSong.cxx: don't use g_build_filename fs/Traits.hxx: add shorter forms of PathTraitsXXX::Build() fs/Traits.hxx: add PathTraitsUTF8::GetLength for consistency fs/AllocatedPath.cxx: don't use g_path_get_dirname fs/Traits: implement GetBase/GetParent/Build using templates fs/Traits.cxx: don't return empty string if parent dir is root fs/Traits.hxx: add FindLastSeparator function to PathTraitsXXX fs/Traits: improve compatibility between PathTraitsFS and PathTraitsUTF8 fs/Traits.hxx: add gcc_nonnull_all where applicable fs/Traits: split PathTraits type into PathTraitsFS and PathTraitsUTF8 -- Denis -- 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
Next part is reimplementing of what I call standard directories API. g_get_system_config_dirs g_get_user_config_dir g_get_home_dir g_get_user_special_dir(G_USER_DIRECTORY_MUSIC) Windows part looks easy there are plenty of standard functions with different levels of obsolescence for that. For Unix version I need some assistance. 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? Second issue: GLib uses two flavors of getpwnam_r() (guarded by HAVE_POSIX_GETPWUID_R and HAVE_NONPOSIX_GETPWUID_R in the code). What should we do with that? https://developer.gnome.org/glib/2.38/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir https://git.gnome.org/browse/glib/tree/glib/gutils.c For reimplementing g_get_user_special_dir(G_USER_DIRECTORY_MUSIC) I think we need to parse user-dirs.dirs file. I didn't any reference documentation on this. However I've found the source http://cgit.freedesktop.org/xdg/xdg-user-dirs/tree/xdg-user-dir-lookup.c I think this could be reused as-is, it does not look very efficient, but this function is going to be called at most once after all. One more question what encoding is this file supposed to have? Bonus question: In the MPD code AllocatedPath::FromUTF8() is called on the results of GLib calls, however I did not find any conversion of encoding in the GLib code (see gutils.c code above). Maybe I'm missing something or maybe this is a bug. -- Denis -- 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
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).
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.
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.
--
Denis
--
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] New event loop implementation
I've added Windows select backend for event loop as well as few fixes. PollGroupEPoll.hxx: add const modifiers where applicable Clock.cxx: provide all arguments for GetProcessTimes event: implement PollGroup based on Windows select configure.ac: code style improvements New backend is enabled by default, I've played with it a bit and it's working for me unlike GLib event loop which is not working at all. -- Denis -- 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
29.11.2013 16:00, Max Kellermann пишет: 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. Hi Max, I appreciate your help in developing this. I'm wondering is there any plan for GLib removal in particular and tasks for new version in general? 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? -- Denis -- 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
30.11.2013 0:27, Max Kellermann пишет: No, there is no grand plan. Things just happen whenever somebody chooses to spend time on the code ;-) I didn't mean plan as a schedule for any specific version. I meant plan as a list of tasks that anybody could pick and implement if they want to help project. 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. This looks very interesting. Especially Android port. I think it would be useful to have a list of things to refactor, if you have enought spare time for documenting that. 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. My login is denis. -- Denis -- 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
I've made a helper patch for simplifying futher work. It adds various configuration options to simplify dealting with different event loop implementations. Here it is: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=46bab7e4b921b79924643bacd08dcd3d1404ceb6 Also during testing I've found that AlsaMixerMonitor depends on epoll event loop (specifically on a AddCall method). This means it could not be compiled when GLib event loop is used. I didn't find immediately obvious way of fixing this, thus decided to leave it as is at the moment. -- Denis -- 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
27.11.2013 19:00, Max Kellermann пишет: That's not perfect but ok, because ALSA is Linux specific, and on Linux we always have epoll (there's no reason not to use it). OK. Do you have any comments on the patch itself? -- Denis -- 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 command line parser
25.11.2013 23:19, Matthias Petschick пишет: Hello, this patch (db238cc23f3bb5c9768d30ae24b99e67a5795203) introduces a segfault upon client connect when mpd is compiled with libwrap enabled. The reason is the removal of g_option_context_parse, which calls g_set_prgname as a side-effect. Some libwrap specific code in ClientNew.cxx and output/HttpdOutputPlugin.cxx depends on the return value of g_get_prgname not being NULL, in particular the invocation of request_init segfaults if the parameter to RQ_DAEMON is NULL. If g_set_prgname never gets called, g_get_prgname always returns NULL. A obvious means of fixing this would be to pass a copy of argv[0] to request_init. Furthermore, it might be a good idea to check for side-effects when removing glib dependencies in the future, not to mention checking return values for NULL before passing them on. Cheers, Matthias Hello Matthias, thanks for the feedback. Looks like Max already fixed one of the affected classes. I'll provide a patch for the second. -- Denis -- 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
[Musicpd-dev-team] Few more fixes
HttpdOutputPlugin.cxx: fix null pointer dereference Main.cxx: initialize winsock before creating IO thread configure.ac: set VERSION_MINOR to 19 -- Denis -- 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
[Musicpd-dev-team] New command line parser
Hi, this time I'm reworking command line parsing to avoid using g_option stuff. Commit: http://git.musicpd.org/cgit/dk/mpd.git/commit/?h=new-cmdline-parserid=db238cc23f3bb5c9768d30ae24b99e67a5795203 Pull from new-cmdline-parser branch of git://git.musicpd.org/dk/mpd.git -- Denis -- 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
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. * However I personally dislike boost due to its hardcore C++ style with lots of templates etc. -- Denis -- 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
24.11.2013 21:06, Max Kellermann пишет: My few cents: Thanks for the comments! - you reordered code in event/Loop.cxx, which makes reading the diff more difficult than necessary That's my fault, probably I was addicted to Add/Modify/Remove trio in every class :-) - the PollGroup/PollGroupImpl indirection adds unnecessary runtime overhead, without any advantage This is done to hide implementation details and use single header for all implementations, but if you prefer to avoid that I could remove the indirection. - why did you remove class EPollFD? Instead, PollGroupEPoll contains this abstraction code, plus the PollGroupImpl code. This is done to encourage using universal PollGroup. - 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. This adds some overhead for the purpose of having single API for all backends. Another option is to use backend specific way to deliver events (e.g. make each backend provide its own variant of EventQueue that could be passed to syscall directly - or even intergrate whole event queue into the PollGroup). Since this is a prototype I've started with simplest approach of using std::deque, but I agree this could be improved. Alternative approach is to use some callback mechanism, but I find pull-style API more convenient to use. - why implement the SocketSet copy constructor? This is done to avoid copying whole fd_array, but instead copy only actually used elements. - 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. I didn't expect this to be merged now. My plan was to polish the code until it is usable for development branch and then propose a merge. But probably we could make this more incremental and keep GLib code for a while. If so I think there should be a configure option to enable new event loop (or disable old). What do you think? I want to add one more backend that uses regular select(). In theory these 4 backends should cover most of the supported platforms. -- Denis -- 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
[Musicpd-dev-team] New event loop implementation
Hi all, 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. Here is a full commit: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=4bcea6ea56fcb4d118d47fea5fa6106ab5883b1d How do you like this apporach? Are there any clear issues with this implementation? I'm currently concerned about (possible) thread-safety problems. What Loop methods are expected to be called from other threads? Any comments are appreciated. -- Denis -- 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
[Musicpd-dev-team] Minor compilation fixes
Hi all, minor compilation fixes for v0.18.x branch: decoder/OggFind.cxx: include stdio.h for SEEK_END definition system/fd_util.h: avoid symbol conflict with statically linked libmpdclient NEWS: add version 0.18.5 change log -- Denis -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Linking MPD 0.18 with libmpdclient statically causes duplicated symbols
Hello list, I'm playing with latest greatest release of MPD (0.18). I've found that both MPD and libmpdclient define socket_cloexec_nonblock function. When statically linking this causes link error due to duplicated symbols. Currently I've made a trivial work around with preprocessor, but I believe there should be a better way. Also I remember myself building 0.18.x branch without trouble (with static libmpdclient). According to git blame both functions existed there for years, but somehow they are preventing build only now. -- Denis -- 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] Various improvements for master branch
05.05.2013 22:17, Denis Krjuchkov пишет: Hi all, Also added two changes with C++ conversion: text_input_stream: convert to class timer: convert to class -- Denis -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ 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 05/05/2013 10:17 PM, Denis Krjuchkov wrote: UpdateWalk, ExcludeList: use Path, file system API, DirectoryReader, log in UTF-8 Found a regression in this commit, please ignore it. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ 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
06.05.2013 12:01, Denis Krjuchkov пишет: On 05/05/2013 10:17 PM, Denis Krjuchkov wrote: UpdateWalk, ExcludeList: use Path, file system API, DirectoryReader, log in UTF-8 Found a regression in this commit, please ignore it. The problem is fixed. -- Denis -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Improve usage of file system API, log in UTF-8
Few more patches with migration to new API. Also I've fixed logging to use UTF-8 where it closely relates with FS operations. StateFile: use file system API, log in UTF-8 SimpleDatabasePlugin: use file system API, log in UTF-8 UpdateIO.cxx: use file system API, log in UTF-8 UpdateWalk.cxx: use FileExists TextFile.hxx: use file system API SongUpdate.cxx: use StatFile PlaylistSave.cxx: use FOpen PlaylistFile.cxx: use file system API ExcludeList.cxx: use FOpen ConfigFile.cxx: use FOpenMode Path.hxx: add GetDirectoryName() method FileSystem.hxx: add FOpen modes for appending files Submitted via git -- Denis -- 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_jan ___ 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
27.01.2013 23:30, Max Kellermann пишет: According to quick searches on the net, neither libevent nor libev seems to work well with Bionic (Android's libc). However, for Android, we could simply roll our own event loop. That's not too hard, and the scalability of libevent/libev is not required here. If we choose to have custom event loops, having custom loop in Windows port seems a wise idea too. It should use WaitForMultipleObjects() instead of select() (like Glib). This could help with implementation of auto update feature because underlying API could notify file system changes via waitable HANDLE. Also WakeFD could be simplified to single event object instead of current poor socket pair. -- Denis -- 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
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. Actually this is very defensive because most characters would fit into 3 bytes according to this table: http://en.wikipedia.org/wiki/UTF-8#Codepage_layout So likely we can lower this to 3x, but I'm not sure. Anyway I agree this should be documented better. -- Denis -- 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
27.01.2013 22:47, Max Kellermann пишет: 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. OK. Let me explain with more details. MPD does not know actual encoding of the path names at build time. This is a runtime option expressed in mpd.conf. MPD needs to convert string between UTF-8 and real path name encoding. OS imposes some limit on path names in bytes. This is expressed by MPD_PATH_MAX. Suppose there is encoding foo and path names are encoded with it. Encoding foo uses 1-byte to represent some code points that occupy 4 bytes in UTF-8. When will that happen? Suppose there is a path name that has MPD_PATH_MAX - 1 code points. Each code point in that path name is encoded in foo with 1 byte, but those code points occupy 4 bytes in UTF-8. This means it would occupy MPD_PATH_MAX - 1 bytes as path name (without nul-terminator). Also this means after converting to UTF-8 it would occupy (MPD_PATH_MAX - 1) * 4 (without nul-terminator). 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? This is approximate (upper bound) limit of number of bytes that are required to represent path name in UTF-8 regardless of what file system encoding is configured at runtime plus one byte for nul-terminator. -- Denis -- 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
I'll rework my patch and move this definition to Path.cxx with comment. I've pushed updated (and rebased) version. -- Denis -- 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
26.01.2013 15:26, Max Kellermann пишет: Can we somehow convert the integer file handle to a WIN32 HANDLE for use in GPollFD? Yes, it's possible. In theory things look simple: create event object with CreateEvent() or WSACreateEvent(), associate event with socket via WSAEventSelect(). This event would be stored in GPollFD instead of actual descriptor. The only complex thing is the need to call WSAEventSelect() everytime set of socket events (i.e. read/write/etc) changes. This could be done in prepare() function for example. How much is it? If it's just a few lines, why not. In practice this looks not so simple. I would like not to copy the code I don't completely understand :-) You could take a lot at it here: http://git.gnome.org/browse/glib/tree/glib/giowin32.c Important functions are: g_io_win32_prepare g_io_win32_check g_io_channel_win32_make_pollfd The only interesting case is G_IO_WIN32_SOCKET. What is a replacement that runs on Linux (POSIX), Windows and Android? Or shall we just roll our own? Well, I'm not expert in network programming at all, but I'd prefer to use something well-tested and documented. Each socket implementation has its own issues (especially winsock). So we might spend a lot of time in writing Yet Another Event Loop library instead of implementing features that actually relate to music playback. You named libevent last time. Do it fit our conditions? On the other-side, implementing our own event library gives the smallest possible overhead. Also it would reduce number of strong dependencies thus MPD would not be limited to platforms supported by chosen event loop library. Bonus question: actually I thought that Android provides the same networking APIs as POSIX systems since it actually uses Linux kernel. But you can prove me wrong. -- Denis -- 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
26.01.2013 6:17, Max Kellermann пишет: 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. I've made improvements to the code and documentation. Also there is one more patch. Please take a look. -- Denis -- 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
I've pushed the fixed version. (Hope I didn't mess it up. Git experience is so painful.) -- Denis -- 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
22.01.2013 1:17, Max Kellermann пишет: 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. Thanks for pointing to such primitive errors. I've pushed the fixed version. Second patch introduces libfs as suggested. -- Denis -- 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
20.01.2013 22:14, Max Kellermann пишет: - 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 Agree, I think we could extract DirectoryReader to the separate header and also introduce new subdir in source tree, i.e.: src/ fs/ FileSystem.hxx FileSystem.cxx DirectoryReader.hxx - ReadLink() should better return a Path object, and Path::Null() on error I've done it so initially, but what would happen in the following situation: // Initializing p1 with some non-null value Path p1 = ...; // Reading the link and suppose ReadLink returns Path::Null() p1 = ReadLink(...); In this case old value of p1 would destroyed via free(), which might under some condition overwrite our errno. - CheckIsRegular(): for me, a name like IsRegularFile() sounds better Agree, those names are invented under effects of reading g_file_test() documentation :-) Couldn't it be something like the following? PathExists()/FileExists()/DirectoryExists() Looks clean and symmetric. - 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. Approach with extra parameter (i.e. follow_symlinks) seems OK for me. However I'm not sure which variant should be default. -- Denis -- 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
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. This gives one extra copying and one extra allocation. Once fs_charset_to_utf8() is replaced with Path::ToUTF8() everywhere implementation could be changed to use stack-allocated buffer* and streaming conversion API: g_iconv_open()/g_iconv()/g_iconv_close(). This eliminates extra allocation. Copying overhead is tolerable IMO for the benefits it provides. * 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). -- Denis -- 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_122912 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] dummy.cxx: remove unused file
This file was used previously to force C++ linkage. It's no longer required because most of the code is C++ anyway. Submitted via git. -- Denis -- 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_122912 ___ 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
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. 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. 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. -- Denis -- 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
18.01.2013 20:51, Max Kellermann пишет: 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. Good. Here is my plan: 1) Further push usage of Path class instead of raw pointers 2) Introduce wrappers for low-level file system APIs: open(), fopen(), stat() and so on. Likely we'll something like PathBuffer to wrap `char buffer[MPD_MAX_PATH]` for functions such as readlink(). Also g_file_test() is extensively used in the code, probably I could re-implement it at this stage because we're anyway migrating from GLib. 3) Once everything uses our wrappers Path implementation finally could be changed to wchar_t. However some questions arise: 0) What's the better names for wrappers: probably the simplest way is to use the same names but put them to separate namespace (i.e. FS::open(), FS::stat()), but what if those functions are defined as macros? stat() is likely to be dependent on _FILE_OFFSET_BITS. Will it hurt our definitions? 1) There would be still some additional copying on Windows for external libraries that expect char* path names. Since there are many of them some reusable way of such conversion need to be implemented. 2) What about command line and configuration file encoding? For the moment those are assumed to be in FS encoding if I'm understanding right. I would keep them as such on POSIX platforms. On Windows there are some options. For command line it's possible to migrate to wchar_t-aware wmain() which would eventually convert its arguments to UTF-8. This would allow usage of existing command line parsing code and code that opens configuration file could construct Path instance by using Path::FromUTF8() method (on POSIX it would be Path::FromFS()). I think the same could be done for reading paths from configuration file. On POSIX those would be still in FS encoding, but on Windows configuration file would have to be stored in UTF-8. This introduces breaking change because in previous version it was assumed to be in 8-bit ANSI encoding. I think such breakage is tolerable for the benefits it gives. P.S. some bonus thoughts on identifier naming style: This is very subjective I know, but I'd prefer to avoid STL-ism such as empty() or c_str(). I understand that you've used such names to give people who read the code some well-known and expected interface. But on the other side it makes the whole code look inconsistent. IsEmpty()/CStr() doesn't seem less clear naming for STL-aware reader, but it preserves consistency. What do you think? -- Denis -- 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
19.01.2013 0:36, Max Kellermann пишет: Yes, why not. OTOH, we could pass Path to our readlink() wrapper, and let the wrapper copy the result into the object. Or make it return a Path. That would be most convenient to use. Adds some overhead, but acceptable for me. If you don't mind some overhead, I'd like to have more natural API. Important thing for wrappers is error management: errno might be messed in between because constructing Path might change it. What are options here? Let's give them better names, to avoid namespace collisions with system macros. OpenFile(), StatFile() etc. There is already open_cloexec() one of them has to be implemented via another or they could be merged altogether. What do you think? Also I'd prefer not to keep procedural interface of opendir()/readdir()/closedir(), but to have some wrapper class. Configuration file is always assumed to be UTF-8. Don't that breaks existing configuration files? Probably you can correct me but I've never seen path conversion there so they are in FS encoding at the moment. 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. I often try to imitate the STL naming, not because I like it (I don't, not at all!), but to allow exchanging container classes more easily. But yes, agree, we could give them better names. Few more style suggestions, very subjective as always: (this isn't strictly related to Path usage, but would be useful to discuss) 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. 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? -- Denis -- 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_122912 ___ 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
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? Some overhead is unavoidable when using high-level features. Having non-trivial destructor provides automatic resource management which is impossible with raw pointers. -- Denis -- 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
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)? Then we could create some similar wrapper that use our FileName class instead of any strings. This would give us clear transition points between internal UTF-8 representation and real file system. 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). What do you think about such approach? -- Denis -- 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
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. 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]) I'd start with std::string/std::wstring. I think those are very optimized* and borrowing a custom solution wouldn't beat std::string performance unless it has some significantly reduced functionality. * especially since we're using C++11: it has some good features such rvalue-references that allow simple move semantics. 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. Yes, this is what I'm talking about. -- Denis -- 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
16.01.2013 17:31, Max Kellermann пишет: 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. 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. -- Denis -- 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
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. 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. This is a drawback I agree. 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. Storage class for what? For protocol FileName (which is always UTF-8 anyway)? 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. -- Denis -- 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
16.01.2013 20:41, Max Kellermann пишет: I guess you can convert right into the std::string, can't you? (Maybe GLib cannot, but I mean technically it is possible.) I see no methods here that return non-const buffer: http://www.cplusplus.com/reference/string/string/ So unless there is a library that can do character conversion char-by-char (i.e. iterator-like API) we'll need some temporary buffer. 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. OK. I'm glad we've finally came to conclusion on this feature. -- Denis -- 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
[Musicpd-dev-team] UTF-8 file names support for Windows
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. To work around this several wrapper functions has been implemented: u_open(), u_fopen(), u_stat() etc. On most platforms they are static inline aliases to their original counterparts. On Windows those expect UTF-8 encoded file name and convert it to UTF-16 then the wchar_t function is invoked (like _wopen(), _wstat() and so on). Stored playlist handling and music directory traversal are simple. MPD deal with them exclusively so after adding u_ prefix everything works. For archive and decoder plugins that expect char* file names there is no Unicode support: UTF-8 names are converted to default ANSI encoding (those are called code pages in WinAPI). Finally main() is replaced with wmain() which uses wchar_t argv. It starts its work by converting command line to UTF-8 and calling mpd_main() Some questions on patch submission: Currently this is implemented in a bunch of feature oriented commits. On the one side this is good because provide descriptive history. On the other side non-ASCII file name handling might be broken between those because some parts still use old encoding. I can combine these commits into more larger ones if this is preferable. Code is available in my git repo (git://git.musicpd.org/dk/mpd.git) under win32-utf8 branch. P.S. This is preliminary version for discussion. It has not been tested thoroughly (but works on my machine). Also I haven't tested compilation on Linux for possible regressions with preprocessor defines. -- Denis -- 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
16.01.2013 3:02, Max Kellermann пишет: 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. Once we have such wrapper probably using native wchar_t underneath would be easy. I actually thought you don't like TCHAR solution (based on our previous discussion some years ago). Seems I'm wrong on this. However I don't think TCHAR-based solution will require less wrappers. We'll still need some wrappers for fopen()/stat()/etc. Also we'll need to wrap functions that deal with file names but not with actual file system (i.e. glob matching, path construction and so on). 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. OK. I've got your complaint here. 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. Well actually this what I didn't want to do. I tried to keep knowledge about wchar_t/8-bit char/UTF-8 char tricks in the smallest number of files. -- Denis -- 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
14.01.2013 13:28, Max Kellermann пишет: All merged. Though we should find a better solution for the last patch. Looks somebody else also encountered this problem and proposed a different patch: http://bugs.musicpd.org/view.php?id=3640 Probably std::list could be modified if done carefully. For me it seems somewhat magical though. -- Denis -- 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
[Musicpd-dev-team] Some more fixes for master branch
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. Submitted via git. -- Denis -- 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
[Musicpd-dev-team] Provide fall-back strndup() implementation
I've made a patch that provides fall-back strndup() for platforms that don't have it. Submitted via git. P.S. master unfortunately still does not work for me. DatabaseLock.cxx defines global db_mutex which could not be used before GLib threading routines are initialized in main(). -- Denis -- 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
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. Global objects are initialized before main() which does required call. -- Denis -- 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
[Musicpd-dev-team] Few more fixes
This time I'm fixing my self mostly. configure.ac: use correct variable for checking libmpdclient presence mpdconf.example: example improvements .gitignore: add src/win/mpd_win32_rc.rc Submitted via git to corresponding branches. -- Denis -- 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
[Musicpd-dev-team] Improve configuration status results
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. Submitted via git: git://git.musicpd.org/dk/mpd.git -- Denis -- 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
[Musicpd-dev-team] One more minor fix (for mpd.conf.example)
It's again me. Improvements for mpd.conf.example in (v0.17.x branch) this time. I've added some missing settings for replay gain as well as basic configuration examples for winmm and openal outputs. -- Denis -- 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
[Musicpd-dev-team] Using GLib for threading primitives on Windows?
As I've saw in git MPD is still going to use GLib's mutex/condvar implementations for Windows. May be we could just take pthreads-win32 instead? http://sourceware.org/pthreads-win32/ -- Denis -- 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?
10.01.2013 16:19, Max Kellermann пишет: That would be another dependency, wouldn't it? Yes, we could do that. You're right. This is another dependency. But it's easy to build it (no transitive dependencies). Also it simplifies code because other platforms use pthreads too (if I'm understanding right). It does not require newer toolchain as well. 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. So practically using GLib API is a transitional solution. I have no objections against 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. This might be a good idea since Vista provides other useful APIs. Such as poll() implementation: http://msdn.microsoft.com/en-us/library/ms741669%28v=vs.85%29.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*) May be newer Debian would be available in the meanwhile before the first 0.18 stable release? I use Kubuntu 12.04. It has condvar API available in mingw-w64. -- Denis -- 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?
10.01.2013 16:52, Max Kellermann пишет: 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. There is libev also (not sure which one is better). One thing I really dislike in current event loop is how event_pipe (or GlobalEvents in master) works on Windows. Windows does not support select()/poll()/etc on pipes. GLib emulates polling using separate reader/writer thread. This is a significant overhead IMO considering what event_pipe is used for. The most straightforward implementation is to use Win32 events. However this requires an event loop that does polling using WaitForMultipleObjects() function instead of select(). Likely this is not possible with libevent/libev but needs checking. Probably separate socket pair could be used instead of pipe. This would at least eliminate extra-thread. -- Denis -- 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?
10.01.2013 17:20, Max Kellermann пишет: 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. I could try that. But unfortunately master does not build for me. OpusReader.hxx uses strndup() which is not available in mingw-w64. Was it meant to be g_strndup()? mingw lacks strndup() at the moment. -- Denis -- 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?
10.01.2013 17:20, Max Kellermann пишет: 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. Just looked at libevent documentation. http://www.wangafu.net/~nickm/libevent-book/Ref4_event.html It seems that it supports user events which makes event_pipe implementation on top of it easy. So there would be no problem here. -- Denis -- 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?
10.01.2013 17:36, Max Kellermann пишет: 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.. According to this http://linux.die.net/man/3/strndup strndup() is defined in POSIX.1-2008. Likely mingw-w64 does not support such recent standard. -- Denis -- 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?
10.01.2013 17:34, Max Kellermann пишет: WTF? It's called Windows programming :-D You could inspect psdk_inc/_socket_types.h What is the practical problem then? After MPD has accepted its two billionths client, further connects will fail? I'm not sure if this is documented behavior or rather implementation detail. Just my observations on my particular system. Since nobody complained about such errors it looks that such situation is a current behavior for many systems. In MPD, there should be a class wrapping a socket descriptor, which hides implementation specific details. That's simplest part 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). So practically this requires adding one more function for each function that deal with sockets? 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 -- Denis -- 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?
10.01.2013 18:17, Max Kellermann пишет: 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 Good, this would require some preprocessor hardcore but looks doable. GLib sources seem to have lots of such hacks I'll consider them as an example. Could the suffix be something like _win32_socket instead of _SOCKET which is ugly and anyway does not clarify what it's for? -- Denis -- 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?
10.01.2013 18:55, Max Kellermann пишет: 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). OK, so what's the plan? Just change signature of existing functions and increment the API version? -- Denis -- 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
[Musicpd-dev-team] Minor fixes: improve libgme detection + add missing file in dist
That's it. Patches are submitted via git: http://git.musicpd.org/cgit/dk/mpd.git/log/?h=v0.17.x git://git.musicpd.org/dk/mpd.git -- Denis -- 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] Build fail zeroconf bonjour
08.01.2013 8:42, Alexander Sack пишет: src/zeroconf-bonjour.c:22:20: fatal error: listen.h: No such file or directory $ find . -name listen.h $ It's called Listen.hxx now as far as I understand. -- Denis -- 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] Binary package for Windows?
07.01.2013 12:45, zw g пишет: Hi Denis, MPD 0.17.3 has just been released as stable version today. (As source code only) Could you provide a stable release of binary for Windows also? Finally it's there. http://www.musicpd.org/download/win32/mpd-0.17.3-win32.zip I've made some quick tests. Unfortunately playing http steams still does not work. Please don't hesitate to write me about any found bugs. -- Denis -- 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] Binary package for Windows?
Forgot to include some changelog related to this particular build: Updates for libraries: curl7.28.1 ffmpeg 1.0.1 openal 1.15.1 sqlite 3071501 flacgit f20164e41ed Newer flac revisions unfortunately does not build for me. Also most of the libraries are now compiled statically. This should improve startup time and simplify upgrades. The only exception is openal-soft. I decided to keep it as shared library because user might want to use system-installed openal implementation instead. This could be done by simply renaming OpenAL32.dll to something else. That's all. Have fun. -- Denis -- 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] Binary package for Windows?
07.01.2013 12:45, zw g пишет: Hi Denis, MPD 0.17.3 has just been released as stable version today. (As source code only) Could you provide a stable release of binary for Windows also? Sure, I'll do this once it is available in git. Unfortunately tarball does not build out-of-the box due to one missing file. I've submitted a patch, but seems it is not approved yet. -- Denis -- 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] Binary package for Windows?
It seems that those $%@%@$#% called github developers removed 'downloads' feature completely from their site. Exiting links will work for some time, but I'll need a different hosting for future releases. -- Denis -- 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] Binary package for Windows?
Thanks for suggestions, guys. Max provided me access to www.musicpd.org This seems the best solution for me. I'll also update README in my github repository so this new location is somehow discoverable. Updating wiki seems a good idea too. -- Denis -- 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_122912 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] [PATCH] Distribute mpd.ico
Hi all, mpd.ico is missing in tarball so eventually it does not work out of the box if targeting Windows. Also I refined my previous patch for libid3tag detection (added entry in NEWS). And finally I figured out correct configure to push to git.musicpd.org. So both patches are pushed there. -- Denis -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Announcing renewed MPD builds for Windows
Hi all, I've finished with first version of renewed MPD build for Windows. You can download it from: https://github.com/downloads/dkrjuchkov/mpd-win32-build/mpd-0.17.3~git-win32-i686.zip SHA-1 sum for paranoids: bc8809a6bccd782dc44857be74a728899053a116 This version is slightly less featured that old one. I'll try to enable more plugins in future. Here is output from configure: ### MPD CONFIGURATION Archive support: (-bzip2) (-ISO9660) (-ZIP) Client support: (+IPv6) (+TCP) (-UNIX Domain Sockets) File format support: (-AAC) (-C64 SID) (+FFMPEG) (+FLAC) (-FluidSynth) (-GME) (+libsndfile) (-MikMod) (-MODPLUG) (+MAD) (+MPG123) (-MP4) (-Musepack) (-OggTremor) (+OggVorbis) (+WAVE) (+WavPack) (-WildMidi) Other features: (+libsamplerate) (-inotify) (+SQLite) Metadata support: (+ID3) Playback support: (-ALSA) (-FFADO) (-FIFO) (+File Recorder) (+HTTP Daemon) (-JACK) (-libao) (-Media MVP) (-OSS) (+OpenAL) (-OS X) (-Pipeline) (-PulseAudio) (-ROAR) (-SHOUTcast) (-Solaris) (+WinMM) Streaming encoder support: (+FLAC) (+LAME) (+Ogg Vorbis) (-TwoLAME) (+WAVE) Streaming support: (-CDIO_PARANOIA) (+CURL) (-Despotify) (-Last.FM) (-Soundcloud) (+MMS) (-SOUP) ## The following features are tested and work: - MP3 playback (both mad and mpg123) - Vorbis playback - FLAC playback - WavPack playback - APE (Monkey's audio) playback - M4A (both Apple lossless and AAC) playback - MP3 streaming output - Vorbis streaming output - WinMM output - OpenAL output (both OpenAL-soft and system) - Stickers The following features are tested and do NOT work: - MP3 streaming playback (fails to connect with timeout, needs more experiments) The rest is untested. Everybody interested in Windows build of MPD are encouraged to test it and report what is working and what is not. If you for some reason want to build your own version build scripts could be found here: https://github.com/dkrjuchkov/mpd-win32-build Both cross-compilation and native build is supported. WARNING! This is poorly tested and experimental stuff. First version of it died by removing its own sources. I will be not be responsible if it kills your home directory or anything else. You have been warned. There is small README that explains build tools and environment setup. You might find code in tools/ too complex to understand. I tried to make it easy to adopt this scripts to any autotools/cmake projects. -- Denis -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] [PATCH] Fix detection of lib3tag under some conditions
Hi all, minor patch that fixes detection of libid3tag https://github.com/dkrjuchkov/mpd-patches/commit/ef6cb703f841411073cfc676a6979e04ddd4654d P.S. I've used my repository dk/mpd.git in the past, but currently can't figure out correct configuration. All tries ended up in fatal: the remote end hung up expectedly. That's why I created temporary github repo. -- Denis -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-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] MPD builds for Windows
03.10.2012 0:49, Avuton Olrich пишет: Please do, I just got done trying to make a quality binary build and it fails to work for some reason Good. For the moment I have some working scripts that can build 0.17.x branch on Windows. They are written in .bat files. I want to rewrite them to something portable enough to run on Windows and Linux (maybe Python?). Unfortunately I'm not good at bash to adopt existing scripts from release utils repository. newer mingw builds need to link with libgcc? For GCC 4.x it's very likely. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-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] rename playlist name(Chinese characters) issue on Windows 7
This looks like a limitation of windows port. There are some conceptual differences in filename handling between windows and Unix-like operating systems. For now MPD can only deal with filenames that can be represented using default windows encoding. It's selected via Language for non-Unicode programs setting in control panel. 02.06.2012 14:16, zw g написал: Ooh, forget to tell that if i do the same operation on Linux/Mac OS X. There is no problem at all. So it is a Windows-Specific question. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] rename playlist name(Chinese characters) issue on Windows 7
02.06.2012 14:38, zw g написал:
But the odd thing is:
I can Save playlist name in Chinese characters. (Although they
displayed in non-readable form in the playlists folder)
In [8]: client.save(old_playlist_name)
In [9]: client.listplaylists()
Out[9]: [{u'last-modified': u'2012-05-26T09:11:01Z', u'playlist':
u'\u5927'}]
Ok, I've just looked at source of MPD and glib and it seems there is a
bug lies in between. MPD uses g_filetest() function to check if file
really exists, but glib redefines g_filetest to be actually
g_filetest_utf8(), which expected file name to be in UTF-8 instead of
windows default encoding.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Multiple soundcards on Windows
As I've said this is the most tricky part.
Windows allocates continuous range of IDs starting with 0.
Probably this is the order that is used in control panel, but I'm not
sure. Also it seems that this order is preserved across reboots until
hardware setup is changed.
You can try the following simple program:
#include stdio.h
#include windows.h
int main()
{
UINT i;
WAVEOUTCAPS caps;
for (i = 0; i waveOutGetNumDevs(); i++) {
waveOutGetDevCaps(i, caps, sizeof(caps));
printf(%d: %s\n, i, caps.szPname);
}
return 0;
}
It will give you imagination how MPD sees your sound cards.
If you can guess what is what after running it you are done.
Otherwise you'll have to brute force those numbers by trying to play
something via MPD with each possible device number.
10.05.2012 19:35, zw g написал:
Thank you very much, Denis.
You give me hope for this.
I know it's stupid, butmay i ask how can i find out the device
number for each sound card?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] output_init: fix bug + winmm_output: fail if wrong device specified instead of using default
Hi all, here they are http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=b75319079d398797dbca1ad5888753f5f319ea34 http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=5fb311feb5a210061661d32181eb2d969b545f93 -- Denis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Some more unused files report
I've made little more investigations on what libraries are actually used.
Here is updated list of unused libraries.
libbz2.dll
libgio-2.0-0.dll
libgmodule-2.0-0.dll
libgobject-2.0-0.dll
libltdl-7.dll
libpcrecpp-0.dll
libpulse-mainloop-glib-0.dll
libpulse-simple-0.dll
libpulsecore-1.0.dll
libzzipmmapped-0-13.dll
postproc-51.dll
Windows eagerly loads dependencies so I simply run MPD and tried to
delete everything that is deletable.
As you can see libbz2 is also unused.
Looks like it statically linked along the road.
If it is supposed to be linked dynamically fix should done somewhere else.
I've made a separate patch because of that.
P.S. It would be useful to have a personal release utils repo for
simple patch delivery.
--
Denis
diff --git a/scripts/mpd-build.sh b/scripts/mpd-build.sh
index 3149a1e..c3abe4c 100755
--- a/scripts/mpd-build.sh
+++ b/scripts/mpd-build.sh
@@ -74,6 +74,15 @@ cp -av ${BINDIR}/*.dll \
## Remove unnecessary libraries
rm ${DISTDIR}/avdevice*
+rm ${DISTDIR}/postproc*
+rm ${DISTDIR}/libgio-*.dll
+rm ${DISTDIR}/libgmodule-*.dll
+rm ${DISTDIR}/libgobject-*.dll
+rm ${DISTDIR}/libltdl-*.dll
+rm ${DISTDIR}/libpcrecpp-*.dll
+rm ${DISTDIR}/libpulse-mainloop-glib-*.dll
+rm ${DISTDIR}/libpulse-simple-*.dll
+rm ${DISTDIR}/libpulsecore-*.dll
rm ${DISTDIR}/libspeexdsp-?.dll
rm ${DISTDIR}/libcharset-?.dll
rm ${DISTDIR}/libasprintf-?.dll
diff --git a/scripts/mpd-build.sh b/scripts/mpd-build.sh
index c3abe4c..474a936 100755
--- a/scripts/mpd-build.sh
+++ b/scripts/mpd-build.sh
@@ -75,6 +75,7 @@ cp -av ${BINDIR}/*.dll \
## Remove unnecessary libraries
rm ${DISTDIR}/avdevice*
rm ${DISTDIR}/postproc*
+rm ${DISTDIR}/libbz2.dll
rm ${DISTDIR}/libgio-*.dll
rm ${DISTDIR}/libgmodule-*.dll
rm ${DISTDIR}/libgobject-*.dll
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] [patch] Exclude libzzipmmapped*.dll from Windows distribution
Hi all,
That file is unused and can be safely excluded.
See patch in attachment.
--
Denis
diff --git a/scripts/mpd-build.sh b/scripts/mpd-build.sh
index 006d244..c68feb3 100755
--- a/scripts/mpd-build.sh
+++ b/scripts/mpd-build.sh
@@ -84,6 +84,7 @@ rm ${DISTDIR}/libcharset-?.dll
rm ${DISTDIR}/libasprintf-?.dll
rm ${DISTDIR}/libzzipwrap*.dll
rm ${DISTDIR}/libzzipfseeko*.dll
+rm ${DISTDIR}/libzzipmmapped*.dll
prep_package ${MPD_LATEST}
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Has mpd release utils repository gone?
Hello all. I've just noticed that mpd release utils repository is no longer listed in http://git.musicpd.org/ Is this is intentional? Should I expect it to be visible again? -- Denis -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Has mpd release utils repository gone?
On Thu, Apr 14, 2011 at 6:48 PM, Avuton Olrich avu...@gmail.com wrote: Unintentional. Not sure why it's happening, I continue to push to it but for some reason it /has/ disappeared. Stay tuned. -- avuton Is it still available via git:// ? If so, could you please post an exact URL? I've never used those scripts directly, but looked at them as a reference when building MPD on Windows. I was lazy and didn't make a clone of repository but always browsed it via web. This worked for me until it disappeared. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Has mpd release utils repository gone?
git://git.musicpd.org/avuton/mpd-release-utils.git That helped, thanks. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ 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 thoughts on filesystem charset in MPD for win32
07.11.2010 14:32, Max Kellermann пишет: a pathname in the GLib file name encoding (UTF-8 on Windows) Probably this is a documentation ambiguity and authors really meant a pathname in the file name encoding Not a show stopper, just a problem we need to be aware of. Those decoders which don't have I/O callbacks may not be able to play some files. Or maybe there is a workaround for narrow characters? I think common ones like libflac, libvorbis and libmad will work. This needs some investigation what exact plugins will be broken by such change. If there is few such plugins we could make a switch to glib stdio. Also, we do not need fully overridable IO. We need a function that takes FILE* instead of file name. Adding such function (if it does not exist yet) is pretty trivial task and we could push such patch to upstream. Even if such change could not be performed we can simply convert file name from UTF-8 to what is used by real stdio. This leads to ugly code, but, again, if there is a few such plugins we could live with that. I'll find out what plugins need improvement in that area. There are also some dirty-hack solutions. We could hijack stdio funcs at compile time or link time to redirect them to glib stdio. This is commonly used to redirect malloc() and friends. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-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] Two minor updates for winmm output plugin
04.11.2010 11:00, Max Kellermann пишет: Both merged, thanks. + UINT id = strtoul(device_name,endptr, 0); + if (*endptr == 0) This is positive for parsing an empty string; please make that: endptr device_name *endptr == 0 Hello, Max. Thanks for reviewing. I've made suggested fix. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Two minor updates for winmm output plugin
Hello all.
I'm back :-)
Two minor updates for winmm_output_plugin
1) test_default_device now checks number of playback devices installed
in system.
If no device is present it returns false.
2) added device configuration option (similar to other output devices).
Device can be specified either by name or by id.
Native API is stupid.
Device identifier is just a magic number (starting from 0).
You have to brute force to find out which id is for you.
Device name could be a solution, but it is truncated to 32 characters.
I've made some workarounds (see comments in code).
Finally, I've made a simple program (see attachment) that prints device
ids along
with device names. Probably it could be integrated in win32 distribution
of mpd.
--
Denis
#include stdio.h
#include windows.h
int main()
{
UINT i;
WAVEOUTCAPS caps;
for (i = 0; i waveOutGetNumDevs(); i++) {
waveOutGetDevCaps(i, caps, sizeof(caps));
printf(%d: %s\n, i, caps.szPname);
}
return 0;
}--
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware,
phishing sites, and compromised hosts - saving your company time,
money, and embarrassment. Learn More!
http://p.sf.net/sfu/hpdev2dev-nov___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Mixer for win32 output
Hello all. I've implemented mixer for win32 output plugin. Patches are in my git repository: git://git.musicpd.org/dk/mpd.git Also, I renamed win32_output_plugin to winmm_output_plugin. Win32 has many sound APIs (WinMM, DirectSound, WASAPI). New name is more correct. This should not affect many users because win32 support for MPD was introduced in current development branch. I'm not sure whenever implementation is free from race conditions. WinMM API itself is thread-safe. But there could be issues with closing output device while it is being queried for current volume. If such condition could appear I have ideas how mixer can be improved. If it couldn't happen probably current implementation is OK. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] convert_filter in the front of the filter chain
Hello Max. Thanks for commenting. On Tue, Sep 28, 2010 at 12:57 PM, Max Kellermann m...@duempel.org wrote: I understand your problem, but most of the time, it's the other way round: people have 24 bit audio (the libmad decoder emits 24 bit audio!), and their sound hardware wants 16 bit. Your change would do the opposite, it would lose more precision. I never thought about breaking existing behaviour. I suggested to add one more convert filter. So advanced users could manually control format before and after filter chain. What we need is better internal logic for conversion. If you need 24 bit anyway, sure, convert to 24 bit as early as possible. OTOH, libsamplerate deals with floating point samples only... It's not so simple! We could make a rule: make that two conversion plugins. Never convert down before the other filters, and never convert up after the other filters. This would get the best our of both cases. It's the almost the same as I thought, but I think manual configuration would be more flexible. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] convert_filter in the front of the filter chain
On Tue, Sep 28, 2010 at 3:27 PM, Max Kellermann m...@duempel.org wrote: Giving the user more control is a good thing (for those who want it), but MPD should do the right thing by default. It is theoretically possible to make MPD do the right conversion choices at the right time. Could the auto adjustment of format be done this way? best_format_sample_rate = max(decoder_sample_rate, output_sample_rate) best_format_sample_size = max(decoder_sample_size, output_sample_size) if best format is more precise than decoded data convert to best format before filter chain if best format is more precise than output format convert to output format after filter chain -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Usage of g_error()
25.09.2010 0:11, Thomas Jansen пишет: Hi everyone! In my recent effort to decimate the bug list present on mantis I stumbled across bug #2995 and its duplicate #3007. Bottomline is: g_error() internally calls abort() which in turn raises SIGABRT leading to a core dump. We currently use g_error in all places where a non-recoverable error occurs. This leads to dumping the core when trying to kill a non-existing mpd-PID or specifying an unknown command line argument which hardly justifies measures as drastic as a core dump. In total, there are 68 individual calls to g_error(). Looks like implementation is not as good as it could be. It will fail to compile in the following situation. if (something_bad_happened) MPD_ERROR(We're going to crash); else save_to_go(); You will have to omit semicolon before else. This case was present in output_all.c I've fixed mpd_error.h and output_all.c in my repository (dk/mpd.git) Also, I've replaced g_error usages in main_win32.c -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Windows service support
24.09.2010 0:51, Max Kellermann пишет: Hi Denis, Hello Max. Thanks for approval. Why don't you get a git repository to submit your code from now on? 1. Denis Krjuchkov 2. alcohold (at) gmail (dot) com 3. dk 4. MPD 5. see attached file ssh-rsa B3NzaC1yc2EBJQAAAIBXN4DiAoseDVxETqBqGtJ8U0Kmlko2npxh31nbXW62ztVnrR8JN2c5keEjvLv0BBMUy+KRDg0GNfCm5ZdKyo++SNpFVHJ9CC2DJjbgvpx6HrqCO0cKszNsJr3SJXJSRujKPLB/DZocVNJCpI9o09ym1+kcT0ICDybFlfv7tQi/2w== alcoh...@gmail.com-- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Windows service support
Hello all again.
I've implemented Windows service support for MPD.
Also this patch adds console handler that traps Ctrl+C and close
window events and performs clean shutdown.
Looks like current implementation does not handle shutdown at all and
simply quits when it gets Ctrl+C.
Some notes on implementation:
I've added PIPE_EVENT_SHUTDOWN because calling g_main_loop_quit() do not
work when called from another thread.
Main thread was sleeping in g_poll() so I needed some way to wake it up.
By some strange reason call close(event_pipe[0]) in event_pipe_deinit()
hangs.
In current implementation that code never reached so that was not a
problem :-)
I've added a conditional to leave event_pipe[0] open on Win32.
Currently there is no registration/unregistration functionality
Service can be registered with SC tool (sc.exe)
I want to implement registration however I'm not sure whenever this
should be a separate program or code inside main MPD program.
Please find patches in the attached files.
/*
* Copyright (C) 2003-2010 The Music Player Daemon Project
* http://www.musicpd.org
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#ifdef WIN32
#include config.h
#include main.h
#include event_pipe.h
#include glib.h
#define WINVER 0x0501
#include windows.h
static int service_argc;
static char **service_argv;
static char service_name[] = ;
static BOOL ignore_console_events;
static SERVICE_STATUS_HANDLE service_handle;
static void WINAPI
service_main(DWORD argc, CHAR *argv[]);
static SERVICE_TABLE_ENTRY service_registry[] = {
{service_name, service_main},
{NULL, NULL}
};
static void
service_notify_status(DWORD status_code)
{
SERVICE_STATUS current_status;
current_status.dwServiceType = SERVICE_WIN32_OWN_PROCESS;
current_status.dwControlsAccepted = status_code == SERVICE_START_PENDING
? 0
: SERVICE_ACCEPT_SHUTDOWN | SERVICE_ACCEPT_STOP;
current_status.dwCurrentState = status_code;
current_status.dwWin32ExitCode = NO_ERROR;
current_status.dwCheckPoint = 0;
current_status.dwWaitHint = 1000;
SetServiceStatus(service_handle, current_status);
}
static DWORD WINAPI
service_dispatcher(G_GNUC_UNUSED DWORD control, G_GNUC_UNUSED DWORD event_type,
G_GNUC_UNUSED void *event_data, G_GNUC_UNUSED void *context)
{
switch (control) {
case SERVICE_CONTROL_SHUTDOWN:
case SERVICE_CONTROL_STOP:
event_pipe_emit(PIPE_EVENT_SHUTDOWN);
return NO_ERROR;
default:
return NO_ERROR;
}
}
static void WINAPI
service_main(G_GNUC_UNUSED DWORD argc, G_GNUC_UNUSED CHAR *argv[])
{
DWORD error_code;
gchar* error_message;
service_handle =
RegisterServiceCtrlHandlerEx(service_name,
service_dispatcher, NULL);
if (service_handle == 0) {
error_code = GetLastError();
error_message = g_win32_error_message(error_code);
g_error(RegisterServiceCtrlHandlerEx() failed: %s,
error_message);
}
service_notify_status(SERVICE_START_PENDING);
mpd_main(service_argc, service_argv);
service_notify_status(SERVICE_STOPPED);
}
static BOOL WINAPI
console_handler(DWORD event)
{
switch (event) {
case CTRL_C_EVENT:
case CTRL_CLOSE_EVENT:
if (!ignore_console_events)
event_pipe_emit(PIPE_EVENT_SHUTDOWN);
return TRUE;
default:
return FALSE;
}
}
int win32_main(int argc, char *argv[])
{
DWORD error_code;
gchar* error_message;
service_argc = argc;
service_argv = argv;
if (StartServiceCtrlDispatcher(service_registry))
return 0; /* run as service successefully */
error_code = GetLastError();
if (error_code == ERROR_FAILED_SERVICE_CONTROLLER_CONNECT) {
/* running as console app */
SetConsoleTitle(Music Player Daemon);
ignore_console_events = TRUE;
SetConsoleCtrlHandler(console_handler,
Re: [Musicpd-dev-team] Windows service support
On Mon, Sep 20, 2010 at 1:34 AM, Christ Schlacta aarc...@gmail.com wrote: if you implement service registration, perhaps the simplest way would be with a pair of .bat files for windows that will register and unregister the service, then there's no unclean code, and it's not difficult to do for the less windows minded. Actually I've already written those .bat files for testing. They are pretty simple one-liners Registration: sc create musicpd binpath= C:\path\to\mpd.exe C:\path\to\mpd.conf displayname= Music Player Daemon depend= Tcpip/AudioSrv Unregistration: sc delete musicpd Service can be started/stopped with net start musicpd and net stop musicpd Service name (musicpd in my examples) can be different. Service will work with any valid name. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
