{5} Assigned, Active Tickets by Owner (Full Description) (8 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

xi (8 matches)

Ticket Summary Component Milestone Type Severity Created
Description
#10 merge map doesnt work as it should ... I think pyyaml defect normal 05/02/06

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.


#34 Making it easier to use libyaml in PyYAML pyyaml defect normal 10/15/06

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).
  1. yaml.dump's and yaml.safe_dump's default Dumpers. Ditto.
  1. 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.)


#67 PySyck does not work on 64 bit machine pysyck defect normal 10/19/07

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 $ 

#76 Sets are dumped with null values pyyaml-legacy defect normal 02/16/08

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.


#45 YAML-RPC pyyaml enhancement normal 02/28/07

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


#57 dump(): Insert a "blank line" after the end of an element pyyaml-legacy enhancement normal 07/09/07

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!


#233 Enable libyaml be built as shared library (DLL) libyaml enhancement normal 02/08/12

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.


#72 Building libyaml with CMake libyaml enhancement minor 12/03/07

I have created a  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  CMakeLists file to my  mini-libyaml branch for the purpose of getting this working.

-- Clive Crous


Note: See TracReports for help on using and creating reports.