free() errors

[wknechtel]

Getting an error similar to this on some tests:

boxologic(28234) malloc: *\ error for object 0x7fc6cbc03b40: pointer being freed was not allocated

This looks like it's most likely a case off poor memory management in the original code, as mallocs are somewhat inconsistent and free() calls are bing made on pointers that weren't allocated in the first place.

My plan is to go through all node creation and deletion and make sure mallocs and frees are handled carefully and thoroghly.

[smarcuss]

First of all, congratulations for this project. Can you help me convert it to pascal code?

[ghost]

Another language and then I might try, but at best, my Pascal skills suck.

Sorry, but good luck. On Jul 3, 2014 10:38 PM, "smarcuss" notifications@github.com wrote:

First of all, congratulations for this project. Can you help me convert it to pascal code?

— Reply to this email directly or view it on GitHub https://github.com/exad/boxologic/issues/7#issuecomment-48004024.

[smarcuss]

Hello Greg

As i informed you in my previous contact, i was working on the conversion of the bin packing source that you provided from C to Pascal.

I'm glad to tell you that the conversion was successful, the code is running smooth in Pascal and generating a XML that is used to create a 3D interactive model in Adobe Flash.

Unfortunately, the 3D model in Adobe Flash revealed a peculiarity, as you can see in the attached images, there are some "gaps" being left between the boxes. This gaps prevent me from packing the bins as shown in the model because the pile will become unstable and it seems to me that some of the bins that were left unpacked may fits in this gaps.

So my question is, have you also encountered this feature in the assembly made by the code? We are very interested in working for a solution to this challenge, our conversion to Pascal was already based in your optimized version of the code and we would like to know if you have made some more optimizations in the packing code.

If you wish, we can send you the 3D model made in Adobe Flash so you can take a look at what we are working in.

PS. The following renders was based on the test case rnd03.txt.

Greeting, Marcos Schmitz

[ghost]

Marcos;

Great work! You've taken it further than I have with the 3d visualization. With the visualization, you can see how the layering approach is used to solve the problem!

I think the spaces are to be expected. In the pdf document included in the /docs directory, on page #50, it states that the algorithm will skip a space within a layer if there is no box that will fit into that space. So, without thinking a whole lot more about the algorithm, you may be stuck. Also, as with all box packing algorithms that use heuristics to minimize run-time and maximize pack density, there is the possibility that the optimum solution will not be found.

I found that for estimating packing and shipping requirements, this is close enough. If you are using a robot to auto-pack pallets, it might not be what you are looking for. Things like box weight are not accounted for (stacking heavy boxes on top of small ones). That can cause a problem as well as having the spaces between layers.

I'm really not sure how I can help. I just took the code from the thesis, got it to compile on a Mac server, wrapped a node.js post url around it and we can call it from any of our internal systems.

...Greg

On Thu, Jul 17, 2014 at 1:18 PM, smarcuss notifications@github.com wrote:

Hello Greg

As i informed you in my previous contact, i was working on the conversion of the bin packing source that you provided from C to Pascal.

I'm glad to tell you that the conversion was successful, the code is running smooth in Pascal and generating a XML that is used to create a 3D interactive model in Adobe Flash.

Unfortunately, the 3D model in Adobe Flash revealed a peculiarity, as you can see in the attached images, there are some "gaps" being left between the boxes. This gaps prevent me from packing the bins as shown in the model because the pile will become unstable and it seems to me that some of the bins that were left unpacked may fits in this gaps.

So my question is, have you also encountered this feature in the assembly made by the code? We are very interested in working for a solution to this challenge, our conversion to Pascal was already based in your optimized version of the code and we would like to know if you have made some more optimizations in the packing code.

If you wish, we can send you the 3D model made in Adobe Flash so you can take a look at what we are working in.

Greeting, Marcos Schmitz

[image: 2014-07-17_093402] https://cloud.githubusercontent.com/assets/8063913/3616709/5af89fe8-0dd6-11e4-8d19-3f7fbca7bbea.jpg [image: 2014-07-17_093530] https://cloud.githubusercontent.com/assets/8063913/3616719/623d9812-0dd6-11e4-83cd-d532c2b29ea5.jpg [image: 2014-07-17_093558] https://cloud.githubusercontent.com/assets/8063913/3616718/623c9c96-0dd6-11e4-8002-ee057960ec1f.jpg [image: 2014-07-17_093643] https://cloud.githubusercontent.com/assets/8063913/3616717/623c20fe-0dd6-11e4-9d3c-565f596d952d.jpg

— Reply to this email directly or view it on GitHub https://github.com/exad/boxologic/issues/7#issuecomment-49336616.

[wknechtel]

Howdy Greg,

So glad you've found some use in this project. I'm curious about your Node.js wrapper - are you writing a boxlist file on the fly and invoking the analyzer once per request, or did you daemonize boxologic to handle requests?

Thanks! Bill

On Jul 18, 2014, at 12:48 PM, Greg Graham notifications@github.com wrote:

Marcos;

Great work! You've taken it further than I have with the 3d visualization. With the visualization, you can see how the layering approach is used to solve the problem!

I think the spaces are to be expected. In the pdf document included in the /docs directory, on page #50, it states that the algorithm will skip a space within a layer if there is no box that will fit into that space. So, without thinking a whole lot more about the algorithm, you may be stuck. Also, as with all box packing algorithms that use heuristics to minimize run-time and maximize pack density, there is the possibility that the optimum solution will not be found.

I found that for estimating packing and shipping requirements, this is close enough. If you are using a robot to auto-pack pallets, it might not be what you are looking for. Things like box weight are not accounted for (stacking heavy boxes on top of small ones). That can cause a problem as well as having the spaces between layers.

I'm really not sure how I can help. I just took the code from the thesis, got it to compile on a Mac server, wrapped a node.js post url around it and we can call it from any of our internal systems.

...Greg

On Thu, Jul 17, 2014 at 1:18 PM, smarcuss notifications@github.com wrote:

Hello Greg

As i informed you in my previous contact, i was working on the conversion of the bin packing source that you provided from C to Pascal.

I'm glad to tell you that the conversion was successful, the code is running smooth in Pascal and generating a XML that is used to create a 3D interactive model in Adobe Flash.

Unfortunately, the 3D model in Adobe Flash revealed a peculiarity, as you can see in the attached images, there are some "gaps" being left between the boxes. This gaps prevent me from packing the bins as shown in the model because the pile will become unstable and it seems to me that some of the bins that were left unpacked may fits in this gaps.

So my question is, have you also encountered this feature in the assembly made by the code? We are very interested in working for a solution to this challenge, our conversion to Pascal was already based in your optimized version of the code and we would like to know if you have made some more optimizations in the packing code.

If you wish, we can send you the 3D model made in Adobe Flash so you can take a look at what we are working in.

Greeting, Marcos Schmitz

[image: 2014-07-17_093402] https://cloud.githubusercontent.com/assets/8063913/3616709/5af89fe8-0dd6-11e4-8d19-3f7fbca7bbea.jpg [image: 2014-07-17_093530] https://cloud.githubusercontent.com/assets/8063913/3616719/623d9812-0dd6-11e4-83cd-d532c2b29ea5.jpg [image: 2014-07-17_093558] https://cloud.githubusercontent.com/assets/8063913/3616718/623c9c96-0dd6-11e4-8002-ee057960ec1f.jpg [image: 2014-07-17_093643] https://cloud.githubusercontent.com/assets/8063913/3616717/623c20fe-0dd6-11e4-9d3c-565f596d952d.jpg

— Reply to this email directly or view it on GitHub https://github.com/exad/boxologic/issues/7#issuecomment-49336616.

— Reply to this email directly or view it on GitHub.

[ghost]

This is a great project! There is true business value in being able to test box pack configurations quickly.

We are invoking the analyzer once per request. When we get to more than ~10 orders per sec, I'm sure I'll want to change that. I don't work for Amazon, and I suspect that it may be sometime before we get to that kind of volume :) For now, it is stable and works.

...Greg

On Fri, Jul 18, 2014 at 3:55 PM, Bill Knechtel notifications@github.com wrote:

Howdy Greg,

So glad you've found some use in this project. I'm curious about your Node.js wrapper - are you writing a boxlist file on the fly and invoking the analyzer once per request, or did you daemonize boxologic to handle requests?

Thanks! Bill

On Jul 18, 2014, at 12:48 PM, Greg Graham notifications@github.com wrote:

Marcos;

Great work! You've taken it further than I have with the 3d visualization. With the visualization, you can see how the layering approach is used to solve the problem!

I think the spaces are to be expected. In the pdf document included in the /docs directory, on page #50, it states that the algorithm will skip a space within a layer if there is no box that will fit into that space. So, without thinking a whole lot more about the algorithm, you may be stuck. Also, as with all box packing algorithms that use heuristics to minimize run-time and maximize pack density, there is the possibility that the optimum solution will not be found.

I found that for estimating packing and shipping requirements, this is close enough. If you are using a robot to auto-pack pallets, it might not be what you are looking for. Things like box weight are not accounted for (stacking heavy boxes on top of small ones). That can cause a problem as well as having the spaces between layers.

I'm really not sure how I can help. I just took the code from the thesis, got it to compile on a Mac server, wrapped a node.js post url around it and we can call it from any of our internal systems.

...Greg

On Thu, Jul 17, 2014 at 1:18 PM, smarcuss notifications@github.com wrote:

Hello Greg

As i informed you in my previous contact, i was working on the conversion of the bin packing source that you provided from C to Pascal.

I'm glad to tell you that the conversion was successful, the code is running smooth in Pascal and generating a XML that is used to create a 3D interactive model in Adobe Flash.

Unfortunately, the 3D model in Adobe Flash revealed a peculiarity, as you can see in the attached images, there are some "gaps" being left between the boxes. This gaps prevent me from packing the bins as shown in the model because the pile will become unstable and it seems to me that some of the bins that were left unpacked may fits in this gaps.

So my question is, have you also encountered this feature in the assembly made by the code? We are very interested in working for a solution to this challenge, our conversion to Pascal was already based in your optimized version of the code and we would like to know if you have made some more optimizations in the packing code.

If you wish, we can send you the 3D model made in Adobe Flash so you can take a look at what we are working in.

Greeting, Marcos Schmitz

[image: 2014-07-17_093402] < https://cloud.githubusercontent.com/assets/8063913/3616709/5af89fe8-0dd6-11e4-8d19-3f7fbca7bbea.jpg>

[image: 2014-07-17_093530] < https://cloud.githubusercontent.com/assets/8063913/3616719/623d9812-0dd6-11e4-83cd-d532c2b29ea5.jpg>

[image: 2014-07-17_093558] < https://cloud.githubusercontent.com/assets/8063913/3616718/623c9c96-0dd6-11e4-8002-ee057960ec1f.jpg>

[image: 2014-07-17_093643] < https://cloud.githubusercontent.com/assets/8063913/3616717/623c20fe-0dd6-11e4-9d3c-565f596d952d.jpg>

— Reply to this email directly or view it on GitHub https://github.com/exad/boxologic/issues/7#issuecomment-49336616.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/exad/boxologic/issues/7#issuecomment-49473002.

[comster]

any interest to npm said wrapper?

[comster]

@swGregGraham I think I'm going to wrap this with node and package it with npm... any suggestions how to approach it? write a tmp file, use spawn, parse the results?

[ghost]

At some point, execve() will become too expensive. But from a practical standpoint, if you are running less than say 2 or 3 calls per second, that will work.

...Greg

On Thu, Mar 26, 2015 at 5:53 PM, Jeff Pelton notifications@github.com wrote:

@swGregGraham https://github.com/swGregGraham I think I'm going to wrap this with node and package it with npm... any suggestions how to approach it? write a tmp file, use spawn, parse the results?

— Reply to this email directly or view it on GitHub https://github.com/exad/boxologic/issues/7#issuecomment-86731561.

[comster]

That would be a good problem to have. I just want to see if the contents will fit a container for each shipment.