__group__	ticket	summary	component	milestone	type	severity	created	_changetime	_description	_reporter
xi	72	Building libyaml with CMake	libyaml		enhancement	minor	2007-12-03T08:11:04-05:00	2012-07-02T14:39:36-04:00	"I have created a [http://www.cmake.org/ cmake] ""meta-build"" file for creating project files for building libyaml.

I have tested the attached cmake file with:
 * Visual Studio 7
 * MinGW Makefiles

It should work fine with Unix Makefiles, KDevelop etc as well (I will test when I get back home in front of a linux box and add a comment here with the results).

I've uploaded the [http://usrsrc.org/svn/forks/forks/libyaml-cmake/CMakeLists.txt CMakeLists] file to my [http://usrsrc.org/svn/forks/forks/libyaml-cmake mini-libyaml branch] for the purpose of getting this working.

--
Clive Crous"	clive.crous@…
xi	57	"dump(): Insert a ""blank line"" after the end of an element"	pyyaml		enhancement	normal	2007-07-09T06:00:51-04:00	2008-07-29T17:14:58-04:00	"Hi, 

For readability it would be great, if you could provide an option for dump() to insert a ""blank line"" (that means a line only consisting of spaces to keep the indenting) when the indenting becomes smaller, with the option to only add this indented blank line, when the indenting goes down by at least two levels (or at least n levels). 

Thanks for creating PyYAML!"	arne_bab@…
xi	233	Enable libyaml be built as shared library (DLL)	libyaml		enhancement	normal	2012-02-08T18:22:34-05:00	2012-02-24T15:06:03-05:00	"Hello,

Thank you for LibYAML!

I'm working on building binary packages of certain libraries to ease the installation on Windows platform.

The compiler used is GCC 4.6.x in both 32 and 64 bits (mingw and mingw-w64 projects)

At configure time, even with --enable-shared was specified, no shared library is generated.

I believe is because Windows do not support undefined symbols and libtool is not building it.

Other project (libffi) uses AM_LTLDFLAGS with -no-undefined for that purpose:

https://github.com/atgreen/libffi/blob/master/configure.ac#L101

I've tried it without success, but also I see LibYAML have undefined symbols that could affect libtool.

It will be great if next version of libyaml can be build as shared library.

Thank you."	luislavena@…
xi	34	Making it easier to use libyaml in PyYAML	pyyaml		defect	normal	2006-10-15T08:33:17-04:00	2012-07-06T08:35:02-04:00	"I really like PyYAML with the libyaml ""plugin"".  I've been using it a lot without any troubles.  So hopefully it will make it out of alpha soon :-).  I have a couple of suggestions with respect to seamlessness between PyYAML in Python mode and PyYAML in C mode.

1. {{{yaml.load}}}'s default {{{Loader}}}.  I would suggest that this becomes {{{CLoader}}} when it is available (i.e., when {{{yaml.cyaml}}} imports successfully).

2. {{{yaml.dump}}}'s and {{{yaml.safe_dump}}}'s default {{{Dumper}}}s.  Ditto.

3. {{{Loader}}} vs. {{{CLoader}}}, {{{Dumper}}} vs. {{{CDumper}}}, {{{Emitter}}} vs. {{{CEmitter}}}, etc.   I would like a uniform way (without using {{{if}}}'s) to subclass from the C version of these classes when they are available, and otherwise the Python versions of these classes.  One possible solution:
  * Python {{{Loader}}} etc. classes get renamed to {{{PyLoader}}}, {{{PythonLoader}}}, {{{PLoader}}}, or something along those lines.
  * {{{Loader}}} becomes an alias to {{{CLoader}}} or {{{PyLoader}}}, whichever is the best available.
  * It could also be possible to control the aliases by a function call, e.g., to force them to the Python version.  Perhaps:
    {{{
def set_language(lang):
  """"""default supported languages: 'C', 'Python'""""""
  import yaml
  global Loader, Dumper, Emitter, ...
  Loader = yaml.__dict__[lang + 'Loader']
  Dumper = yaml.__dict__[lang + 'Dumper']
  Emitter = yaml.__dict__[lang + 'Emitter']
  ...
try:
  set_language('C')
except KeyError:
  set_language('Py')
}}}

Currently all of my code that imports {{{yaml}}} starts like this:

{{{
import yaml
if hasattr (yaml, 'CLoader'):
  Loader = yaml.CLoader
else:
  Loader = yaml.Loader
if hasattr (yaml, 'CDumper'):
  Dumper = yaml.CDumper
  SafeDumper = yaml.CSafeDumper
else:
  Dumper = yaml.Dumper
  SafeDumper = yaml.SafeDumper
def yaml_load (x):
  return yaml.load (x, Loader = Loader)
def yaml_dump (x):
  return yaml.dump (x, Dumper = Dumper)
def yaml_safe_dump (x):
  return yaml.dump (x, Dumper = SafeDumper)
}}}

Then I use {{{yaml_load}}} in place of {{{yaml.load}}}, {{{yaml_dump}}} in place of {{{yaml.dump}}}, and I use {{{Loader}}} etc. whenever I want to subclass.  Needless to say, it's annoying to have to repeat this in all of my projects.

Another motivation for all this, I think, is that it's not obvious out-of-the-box how to use {{{CLoader}}} and friends.  I don't think the average user should have to know about this distinction.  If libyaml is installed, it should just work (faster).

A more minor point: Once out of alpha, could we replace {{{setup.py}}} and {{{setup_with_libyaml.py}}} with a single {{{setup.py}}} that does the right thing depending on what's available in the environment?  (If PyRex is installed, I don't see why we shouldn't install, unless a command-line option tells us not to.  Or even if RyRex isn't installed, as suggested in anotehr ticket.)"	edemaine@…
xi	10	merge map doesnt work as it should ... I think	pyyaml		defect	normal	2006-05-02T11:56:03-04:00	2006-05-03T14:33:20-04:00	"Hi,

It seems that the user defined directives are ignore when just after the merge key.

I have the following yml code

{{{

 Chip:
  Name: ""CHIPNAME""
  RegSize: 4
  << : !include
       file_name: ymlInclude2.yml
 

}}}

Where include is my own directive which just reads in a file

{{{

class Include(yaml.YAMLObject):
    yaml_tag = '!include'
    @classmethod
    def from_yaml(cls, constructor, node):
        # Convert the node to a dictionary
        attributes = constructor.construct_mapping(node)
        # Convert spaces into underlines
        if attributes.has_key('file_name'):
            common.log.info(""We are reading in file: "" + attributes['file_name'])
            db = loadYAMLFile(attributes['file_name'])
            # print db
            return db
        else:
            raise KeyError, ""!Include directive must have an attribute file_name""

    @classmethod
    def to_yaml(cls, representer, person):
        pass # we havent implemented this
        # Create mapping node
    def __init__(self, file_name=None):
        self.file_name = file_name

}}}


But the directive doesnt get called when I  use the merge key.
What I get when I run is this python structure.

{{{
{'Chip': 
      {'file_name': 'ymlInclude2.yml', 
       'Name': 'CHIPNAME', 'RegSize': 4}, 
'FormatVersion': 1}

}}}

So it seems that the directives are ignore when using the merge key.




"	anonymous
xi	67	PySyck does not work on 64 bit machine	pysyck		defect	normal	2007-10-19T16:59:07-04:00	2009-08-21T00:13:04-04:00	"Trying to use latest version of syck from CVS and PySyck from svn on the 64 bit machine.

When compiling syck regular built syck we get:
{{{
mtebeka@news01:src - 13:55 $ cd pysyck-trunk/
/home/mtebeka/src/pysyck-trunk
mtebeka@news01:pysyck-trunk - 13:55 $ rm -fr build/
mtebeka@news01:pysyck-trunk - 13:55 $ python setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.5
creating build/lib.linux-x86_64-2.5/syck
copying lib/syck/__init__.py -> build/lib.linux-x86_64-2.5/syck
copying lib/syck/dumpers.py -> build/lib.linux-x86_64-2.5/syck
copying lib/syck/loaders.py -> build/lib.linux-x86_64-2.5/syck
running build_ext
checking for syck.h
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I../syck/lib -I/usr/local/include/python2.5 -c ./_check_syck.c -o ./_check_syck.o
In file included from ../syck/lib/syck.h:39,
                 from ./_check_syck.c:2:
../syck/lib/syck_st.h:12: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:13: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:27: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:28: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:29: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:30: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:31: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:32: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:33: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:33: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:34: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:34: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:36: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:44: warning: function declaration isn’t a prototype
In file included from ./_check_syck.c:2:
../syck/lib/syck.h:385: warning: function declaration isn’t a prototype
../syck/lib/syck.h:412: warning: function declaration isn’t a prototype
../syck/lib/syck.h:438: warning: function declaration isn’t a prototype
../syck/lib/syck.h:439: warning: function declaration isn’t a prototype
../syck/lib/syck.h:440: warning: function declaration isn’t a prototype
checking for libsyck.a
gcc -pthread ./_check_syck.o -L../syck/lib -lsyck -o ./_check_syck
checking syck version
syck version: 0.61
building '_syck' extension
creating build/temp.linux-x86_64-2.5
creating build/temp.linux-x86_64-2.5/ext
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I../syck/lib -I/usr/local/include/python2.5 -c ext/_syckmodule.c -o build/temp.linux-x86_64-2.5/ext/_syckmodule.o
In file included from ../syck/lib/syck.h:39,
                 from ext/_syckmodule.c:3:
../syck/lib/syck_st.h:12: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:13: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:27: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:28: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:29: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:30: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:31: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:32: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:33: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:33: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:34: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:34: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:35: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:36: warning: function declaration isn’t a prototype
../syck/lib/syck_st.h:44: warning: function declaration isn’t a prototype
In file included from ext/_syckmodule.c:3:
../syck/lib/syck.h:385: warning: function declaration isn’t a prototype
../syck/lib/syck.h:412: warning: function declaration isn’t a prototype
../syck/lib/syck.h:438: warning: function declaration isn’t a prototype
../syck/lib/syck.h:439: warning: function declaration isn’t a prototype
../syck/lib/syck.h:440: warning: function declaration isn’t a prototype
ext/_syckmodule.c: In function ‘PySyckEmitter_node_handler’:
ext/_syckmodule.c:1691: warning: passing argument 2 of ‘PyDict_Next’ from incompatible pointer type
ext/_syckmodule.c:1722: warning: passing argument 3 of ‘PyString_AsStringAndSize’ from incompatible pointer type
ext/_syckmodule.c: In function ‘PySyckEmitter_mark’:
ext/_syckmodule.c:1921: warning: passing argument 2 of ‘PyDict_Next’ from incompatible pointer type
gcc -pthread -shared build/temp.linux-x86_64-2.5/ext/_syckmodule.o -L../syck/lib -lsyck -o build/lib.linux-x86_64-2.5/_syck.so
/usr/bin/ld: ../syck/lib/libsyck.a(emitter.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../syck/lib/libsyck.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
mtebeka@news01:pysyck-trunk - 13:55 $ 
}}}

So I've compiled syck with `CFLAGS=-fPIC ./configure && make`

Then PySyck builds just fine, however:
{{{
mtebeka@news01:lib.linux-x86_64-2.5 - 13:57 $ python -c 'import syck; syck.dump(""hello"")'
Fatal Python error: PyEval_RestoreThread: NULL tstate
Aborted
mtebeka@news01:lib.linux-x86_64-2.5 - 13:57 $ 
}}}"	miki@…
xi	76	Sets are dumped with null values	pyyaml		defect	normal	2008-02-16T02:42:25-05:00	2012-08-07T06:32:51-04:00	"Dumping sets looks kind of ugly. You get:

'!!set {1: null, 2: null, 3: null}'

instead of

'!!set {1, 2, 3}'

This looks even worse when each element in the set is a bit more complicated."	anonymous
xi	45	YAML-RPC	pyyaml		enhancement	normal	2007-02-28T18:06:11-05:00	2007-03-20T12:42:35-04:00	"Contains a client (yamlrpclib.py), a server (SimpleYAMLRPCServer.py) and base classes for RPC communication (yamlrpcbasic.py). 

For simple testing, run the server and then the client on the same machine. Both use port 8002, but any other port is acceptable.

Caveats - See:
  
http://sourceforge.net/mailarchive/forum.php?thread_id=31728889&forum_id=1771
"	pkmurphy at postmaster dot co dot uk