Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installation improvements #723

Merged
merged 103 commits into from
Mar 21, 2017
Merged

Installation improvements #723

merged 103 commits into from
Mar 21, 2017

Conversation

TheJJ
Copy link
Member

@TheJJ TheJJ commented Jan 26, 2017

  • normalize python prefix (fixes Normalize install prefixes in cmake #690)
  • install game launcher (fixes Install global game binary #709)
  • blacklist pythontex.py (fixes blacklist pythontex in the buildsystem #708)
  • cache locating python and python modules
  • ninja build system support
  • enable repo assets directory depending on devmode
  • union-mount all possible asset search paths (/usr/share, /home, --assets, ...)
  • modernized file reading
    • use std::istream, std::getline etc
  • filesystem abstraction c++ interface (Filesystem abstraction C++ interface #630)
    • abstraction layer through python
    • abstraction layer through c++ stdlib
    • filelike support through python
      • reading
      • writing
    • filelike support through c++ stdlib
      • reading
      • writing
    • wrapping the C++ api for python
      • the c++ objects can be passed again to python
      • filesystemlike and filelike api must be wrapped in the other direction again
  • integrate util::Path all over the codebase
    • reading QML files and watch root dir
    • improve docx reading
    • audio manager
    • asset manager
      • texture loading
      • sound loading
  • generic .call() method for python objects
  • random fixes and improvements
  • integration of Update unit.py #718 because this pullrequests requires a reconversion anyways
  • visgrep interface cutter optimizations (faster by factor ~50)
  • slp parser optimizations (faster by factor ~40) (fixes Write slp parser in cython #431)
  • virtual file reading for audio system
  • cvar default loading

works towards #691

@TheJJ TheJJ added area: assets Involved with assets (images, sounds, ...) area: buildsystem Related to our cmake/python buildsystem improvement Enhancement of an existing component labels Jan 26, 2017
@TheJJ TheJJ mentioned this pull request Jan 26, 2017
2 tasks
@TheJJ TheJJ force-pushed the searchpaths branch 2 times, most recently from 77fab4c to 92906b0 Compare January 27, 2017 20:29
@zuntrax zuntrax added this to the v0.4.0 milestone Jan 28, 2017
@TheJJ TheJJ force-pushed the searchpaths branch 2 times, most recently from f776e0e to 72c628c Compare February 1, 2017 10:13
@TheJJ TheJJ force-pushed the searchpaths branch 6 times, most recently from a0eb469 to 40ba5cc Compare February 5, 2017 19:30
@TheJJ TheJJ mentioned this pull request Feb 7, 2017
@TheJJ TheJJ force-pushed the searchpaths branch 2 times, most recently from 1bb36da to fda12d8 Compare February 12, 2017 23:46
Copy link
Contributor

@Tomatower Tomatower left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found some plain-old-C stuff that should be easy fixing and not copying data on lioad

if (unlikely(strbuf.size() <= line.size())) {
strbuf.resize(line.size() + 1);
}
memcpy(strbuf.data(), line.c_str(), line.size() + 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why memcpy here?

std::copy(line.c_str(), line.c_str()+line.size(), std::back_inserter(strbuf));

if (unlikely(strbuf.size() <= line.size())) {
strbuf.resize(line.size() + 1);
}
memcpy(strbuf.data(), line.c_str(), line.size() + 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

memcpy?

memcpy(strbuf.data(), line.c_str(), line.size() + 1);

// use the line copy to fill the current line struct.
int error_column = current_line_data.fill(strbuf.data());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually - Why not give the line.data() directly into the fill() method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because the fill method will modify the data, and i think that line.c_str() is const.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the fill method modify the data? strbuf is rewritten for every line

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was based on strtok once, not sure if it still does.

Copy link
Contributor

@Tomatower Tomatower Feb 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah now I see what you mean... It is finally consumed here - and there write access is required - which is still not completely broken - if the string is not modified in length one can use &line[0] - and continue to avoid any copy

memcpy(strbuf.data(), line.c_str(), line.size() + 1);

// use the line copy to fill the current line struct.
int error_column = current_line_data.fill(strbuf.data());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here - use line.data() or

@TheJJ
Copy link
Member Author

TheJJ commented Feb 13, 2017

I'll clean the whole csv reading up, it's really a mess...

@jonaspm
Copy link

jonaspm commented Feb 17, 2017

Hello everyone, I am liking this project but... why use docx instead of a more documented and libre option as .odt?

thanks in advance.

@elnabo
Copy link
Contributor

elnabo commented Feb 17, 2017

If I remember correctly the .docx files are in fact csv files.

@VelorumS
Copy link
Contributor

VelorumS commented Feb 17, 2017

@jonaspm, in other words: it's not that docx.

@TheJJ
Copy link
Member Author

TheJJ commented Feb 17, 2017

This file suffix is purely a troll, in fact the files are just plain text. We wanted to use them as as "temporary solution" until we have nyan, but this turned out to be way more complicated, so we still have them as of today, but they will go away at least after my master thesis about nyan. 😛

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: assets Involved with assets (images, sounds, ...) area: buildsystem Related to our cmake/python buildsystem improvement Enhancement of an existing component packaging Bundling openage for distribution
Projects
None yet
8 participants