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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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()
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
--
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
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.
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
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
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
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
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':
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
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
--
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
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
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
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
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
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
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.
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
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
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
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
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
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
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 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
91 matches
Mail list logo
