Suggestion: Docker container about printabrick HOT 11 OPEN

Yes, it would. I will try to create one in the near future when I have time.

from printabrick.

Given the nature of the content, the website could run on multiple servers, good idea.

from printabrick.

@hroncok What database do you use? does it matter? trying to work on a docker image. I think that's the last deps I need to get it working.

from printabrick.

so sqlite does not work. mysql looks promising just had to configure the php docker image to install the pdo mysql client

so I am getting stuck on loading models LDraw library
[ 1489 / 11784] [========>-------------------------------------------------------------] 12% (11 secs/1 min ) (2452.dat)
Here is the current docker file I have:

FROM php:7.1.32-zts-stretch

RUN apt update
RUN apt install -y apt-transport-https vim wget git admesh povray python3-setuptools gnupg libzip-dev

RUN docker-php-ext-configure zip --with-libzip
RUN docker-php-ext-install zip pdo_mysqlp

# install elasticsearch
RUN wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
RUN echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee -a /etc/apt/sources.list.d/elastic-7.x.list
RUN apt update && apt install elasticsearch

RUN /bin/systemctl enable elasticsearch.service

#install node 8 because newever version go kaboom
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt install -y nodejs

#install ldview
RUN wget https://github.com/tcobbs/ldview/releases/download/v4.3/ldview-osmesa_4.3-stretch_amd64.deb
RUN apt install -y /ldview-osmesa_4.3-stretch_amd64.deb

#install stl2pov
RUN git clone https://github.com/rsmith-nl/stltools.git
WORKDIR stltools
RUN python3 setup.py install
WORKDIR /

#install composer
RUN wget https://getcomposer.org/installer
RUN php installer
RUN mv composer.phar /usr/local/bin/composer

RUN git clone https://github.com/hubnedav/PrintABrick.git
WORKDIR /PrintABrick
RUN composer install

# setup front ned
RUN npm install
RUN npm install bower -g

RUN bower install --allow-root
RUN node_modules/gulp/bin/gulp.js

RUN apt install -y mysql-server
#configure mysql
#start and let root access to server

#RUN php bin/console doctrine:database:create
#RUN php bin/console doctrine:schema:create

#RUN php bin/console doctrine:fixtures:load

#RUN php bin/console app:init

from printabrick.

Any news on this? I have an R710 that I'd be interested in deploying a docker container of this.

from printabrick.

@marklester

from printabrick.

@marklester the problem you're running into is related to the memory_limit of PHP, without explicitly setting this in a php.ini file, it'll default to 128M. The PHP script which does the loading of models appears to have a memory leak.

There appears to be an attempt to catch this leak in ModelLoader.php during the loadAll method, but the latest models from LDraw appear to exceed that limit. Specifically with the filename 2453.dat, which appears to be an empty file or "moved" to a different parts file (there are more I'm sure):
https://www.ldraw.org/parts/official-part-lookup.html?folder=parts&partid=2453

In those cases, there appears to be a recursive loop at line 241, which will eventually exhaust the available memory on the system, causing the error. For the few I've looked at, this involves a case where Part 1 says Part 2 is it's parent, while Part 2 says Part 1 is it's parent .. thus the infinite loop. I'm suspecting the problem is in the getParentId method of the same file.

I didn't use the app:init route, rather performed them all in a docker-entrypoint.sh so each time the docker container is started, it'll get the most recent database from LDraw and Rebickable. Essentially converting the InitDataCommand.php into a bash script. Though this still is not a good approach towards data management.. I may look into a better ETL method after I can get this running locally.

from printabrick.

@szelenka I'm trying to run this locally, solved the issue mentioned above with the memory by setting, but I get this in the command line:

Downloading LDraw library
------------------------------------------------------------------------------
Loading file from: http://www.ldraw.org/library/updates/complete.zip
[54.05 MB / 54.05 MB] [======================================================================] 100% (16 secs/16 secs)
LDraw libary downloaded
------------------------------------------------------------------------------
Loading models from LDraw library: /private/var/tmp/printabrick.fQhcxf/ldraw/
------------------------------------------------------------------------------
[ 1076 / 14038] [=====>----------------------------------------------------------------]   7% ( 1 sec/13 secs) (19159.dat)
[ 1079 / 14038] [=====>----------------------------------------------------------------]   7% ( 1 sec/13 secs) (191766.dat)
[ 1981 / 14038] [=========>------------------------------------------------------------]  14% (2 secs/14 secs) (2452.dat)
PHP Fatal error:  Allowed memory size of 2147483648 bytes exhausted (tried to allocate 262144 bytes) in /Applications/MAMP/htdocs/PrintABrick/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php on line 1582

I've raised the memory also to be unlimited, but there seems to be an issue with those .dat files, can it be? You were talking about infinite loop, do you think this is the case?
Also, if you have a dockerfile could you share please? Were you able to run locally?

from printabrick.

@alecat88 I gave up on trying to get the site to work.

The core logic for the CLI commands is useful for converting the LDraw files into a STL file, but even after that, I've found that I'm spending a lot of time in Fusion 360 patching them up and adjusting the tolerances to work with my printer.

So while it's useful to have a site with all the STL files pre-processed, in practice I typically lookup the part number on bricklink, then grab it from LDraw and convert it to STL directly, import into Fusion 360 to patch, and print.

from printabrick.

@szelenka This does seem to be the case; the workflow to get TO the part is great but then the actual data is rough.

Are you able to get a consistent sizing into F360 and then into your slicer? It seems like every thing I pull through Ldraw, stitch/wrap in F360, export as mm, always ends up... off.

Although come to think of it I was starting from Bricklink Studio sometimes...even then I would think it would just use the native Ldraw part when it came down to it.

from printabrick.

The resolution of the models from ldraw is not the best, and sometimes their dimensions are questionable. I usually import them into F360 as a reference and create my own model from they're. But I'm also usually doing 5-10x size

from printabrick.